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
email@hidden
//======================
