Re: msleep() with PDROP
Re: msleep() with PDROP
- Subject: Re: msleep() with PDROP
- From: Terry Lambert <email@hidden>
- Date: Mon, 10 Dec 2007 16:42:23 -0800
On Dec 9, 2007, at 1:30 PM, Rick Macklem wrote:
I feel a bit silly responding to my own posting, but I think I
figured it
out and thought I'd see if I got it right:
In various places in the xnu kernel I see code like the following:
#1 msleep(<event>, my_mutex, PDROP, "mysleep", 0);
lck_mtx_lock(my_mutex);
So, why do the above instead of:
#2 msleep(<event>, my_mutex, 0, "mysleep", 0);
My understanding was that msleep() would release the mutex and then
re-acquire it, if PDROP isn't specified.
Is there any fundamental difference between door #1 and door #2?
#1 - always releases/acquires the mutex, allowing other threads
wanting
the mutex to get a turn
#2 - holds the mutex unless it sleeps
Does this make sense (ie. #1 is used to give other threads a chance to
lock the mutex even if the msleep() doesn't actually sleep)?
Still seems a little weird to call msleep() unless you need to sleep.
If you specify PCATCH as well, then it's possible for a pending signal
to interrupt you before you actually get to sleep. If you are getting
a lot of signals, then it's likely that the PDROP would be needed to
allow another thread that also needs the mutex to make any progress at
all.
In general, you're going to want to specify a PCATCH so that you don't
end up being non-interruptible, if you are making the call on behalf
of a user space process that may decide that it doesn't want to block
forever. If it's a kernel thread, you won't want PCATCH in most
cases, unless you call the sleep directly with a continuation function.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden