site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com 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? 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)? -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... 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: #1 - always releases/acquires the mutex, allowing other threads wanting the mutex to get a turn #2 - holds the mutex unless it sleeps 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. This email sent to site_archiver@lists.apple.com