This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author kristjan.jonsson
Recipients beazley, dabeaz, flox, kristjan.jonsson, loewis, pitrou, techtonik, torsten
Date 2010-04-15.15:39:51
SpamBayes Score 6.5430584e-07
Marked as misclassified No
Message-id <1271345993.52.0.689698262359.issue8299@psf.upfronthosting.co.za>
In-reply-to
Content
Oh dear.  I was assuming that the mutex+condition variable were the actual implementation mostly in use on pthreads.  This is because of David's GIL open talk at pycon, where we were looking at the source and bickering about the placement of "pthread_cond_signal()" being after the "pthread_mutex_unlock()" call.  

In which case, more than half of this thread is invalid.  I could, perhaps, start a new defect: "semaphore emulation using condition variable is broken".

However, I just asked a colleague with a os X to compile python 2.7 and _POSIX_SEMAPHORES isn't defined, and so, it is running using the emulation.  Why, I wonder?  Isn't it defined in unistd.h?

Martin, I don't know if you were suggesting that a "fair" mutex would make the emulated semaphore fair too.  You probably weren't, but just in case, the fairness of the mutex is immaterial because it is only held for a short time to guard the internal state of the "semaphore".  You won't see threads queing up on it, but they will queue on the Contition variable.
History
Date User Action Args
2010-04-15 15:39:53kristjan.jonssonsetrecipients: + kristjan.jonsson, loewis, beazley, pitrou, techtonik, flox, dabeaz, torsten
2010-04-15 15:39:53kristjan.jonssonsetmessageid: <1271345993.52.0.689698262359.issue8299@psf.upfronthosting.co.za>
2010-04-15 15:39:51kristjan.jonssonlinkissue8299 messages
2010-04-15 15:39:51kristjan.jonssoncreate