| Terry,
OK, got the idea of that solution.
I found another reference to this issue, is it a good one and does it cover my needs?
> > typedef struct pthread_mutex_recursive_np_t { > pthread_mutex_t mutex; > pthread_t owner; > UInt32 count; > } pthread_mutex_recursive_np_t; > > void pthread_mutex_lock_recursive_np(pthread_mutex_recursive_np_t *mutex) > { > pthread_t self; > > self = pthread_self(); > if (mutex->owner != self) > { > pthread_mutex_lock(&mutex->mutex); > mutex->owner = self; > mutex->count = 1; > } > else > mutex->count += 1; > } > > void pthread_mutex_unlock_recursive_np(pthread_mutex_recursive_np_t > *mutex) > { > if (--mutex->count == 0) > { > mutex->owner = NULL; > pthread_mutex_unlock(&mutex->mutex); > } > }
======= Cheers, Erez
On Jul 19, 2007, at 10:01 AM, Terry Lambert wrote: If funcB has to be callable unlocked somewhere, then:
funcA() { lock mutex funcB_locked() do stuff... unlock mutex }
funcB() { lock mutex funcB_locked() unlock mutex }
/* MUST be called with mutex held! */ funcB_locked() { do stuff... }
We do this sort of thing in the kernel in a number of places, where reference counts would be inappropriate.
-- Terry
On Jul 18, 2007, at 9:36 PM, Erez Kaplan wrote: Terry,
Thanks for the explanation.
I am facing a some what strange sequence of calling (forced by PC porting) which looks something like this: Currently I get a deadlock situation. How would you outline handling this deadlock?
funcA() {
lock mutex funcB() do stuff... unlock mutex }
funcB() {
lock mutex do stuff... unlock mutex }
Cheers, Erez
On Jul 19, 2007, at 7:24 AM, Terry Lambert wrote:
On Jul 18, 2007, at 8:54 PM, Erez Kaplan wrote: On Jul 18, 2007, at 10:00 PM, Terry Lambert wrote: On Jul 18, 2007, at 2:37 AM, Erez Kaplan wrote: Hi,
10.4.9+ 10.5 How do I obtain a Kernel Recursive mutexe?
The available api does not support this. lck_mtx_alloc_init(gmutex_grp_m, LCK_ATTR_NULL)
You don't; this is what reference and use counts are for.
Can you explain a bit more or give reference to an example.
For example, all thread reentrant FSs will take an I/O reference on a vnode, and use that reference to prevent the FS from being unmounted out from under an operation in progress, rather than holding a lock over the complete operation (thus unnecessarily serializing all other I/O to the vnode). Here is a simplified design pattern:
some function(object) lock mutex atomic increment reference count unlock mutex
... long duration operation ...
lock mutex atomic decrement reference count unlock mutex
/* wake up destroy routine; destroy routine may fail acquisition race */ if !reference count wakeup(object)
...
destroy(object) lock mutex again: /* Don't destroy the object while someone is using it */ if reference count msleep(mutex, object) goto again /* avoid race */
/* last reference gone, OK to kill it */ destroy object unlock mutex
-- Terry
//====================== Erez Kaplan Senior software engineer OSX //======================
//======================
Erez Kaplan Senior software engineer OSX //======================
|