[concurrency-interest] On park and unpark

Nathan and Ila Reynolds nathanila at gmail.com
Fri Aug 25 13:01:14 EDT 2017

Thank you for clarifying the details.  I was not fully up to speed.

Last I heard (and this is old hearing), unpark() had to acquire the 
mutex before checking the park permit flag.  From the sound of it, using 
futex directly would allow for checking the park permit flag without 
acquiring the mutex.  Hence, fewer atomic operations (i.e. no need to 
acquire and release the mutex).  However, I could be very wrong since I 
have never dug into the details and I am only working off of hearsay.


On 8/25/2017 10:53 AM, Andrew Haley wrote:
> On 25/08/17 17:49, Nathan and Ila Reynolds wrote:
>> Several years ago, I saw Linux futex perform poorly in the kernel.
>> Futex was getting a bad rap by others as well.  In my experience, the
>> kernel would spend a lot of CPU time dealing with futexes.  I do not
>> remember the circumstances that cause this scenario.  So, I recommend
>> proceeding with caution and lots of testing.  Perhaps, this caution is
>> not warranted and the problem was fixed in the kernel.
> That's won't help, because Linux mutexes always use futex.  There's
> no way to bypass a futex call if you block.
>> For the blocking case, I would guess there would not be much difference
>> in performance.
>> I recommend running some microbenchmark tests for the non-blocking case
>> (i.e. unpark() before park()).  You might see a CPU performance gain.
> Really?  I doubt it, because the park permit flag would be set so the
> park() return immediately.  The only time that wouldn't happen is a
> narrow race condition between that flag being tested and a mutex being
> acquired.


More information about the Concurrency-interest mailing list