Re: Kernel Recursive mutexes 10.4.9 ++
Re: Kernel Recursive mutexes 10.4.9 ++
- Subject: Re: Kernel Recursive mutexes 10.4.9 ++
- From: Terry Lambert <email@hidden>
- Date: Thu, 19 Jul 2007 00:01:31 -0700
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
email@hidden
//======================
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden