|
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 //======================
|