> + Due to misguided paternalism, POSIX doesn't want a thread to do
> pthread_mutex_lock on a mutex that the thread already has locked. But
> Guido doesn't write any code that _doesn't_ do that <wink>, so
> pthread_mutex_lock can't be used directly in the waitflag==1 case of
> acquire_lock. The attached uses a busy loop on pthread_mutex_trylock
> instead, which sucks. Python's lock semantics should probably be
> implemented as a combination of a POSIX condition variable and a POSIX
> mutex; but I don't have the condition variable docs at hand, and don't
> personally care how wasteful the busy loop is anyway.
Oops. I guess this comes from both me and Sjoerd (the designer of
thread.c) our Amoeba background. This was a distributed operating
system with a thread implementation and not much else in its
microkernel. Amoeba only had (has?) mutexes and we got quite clever
in abusing them for other synchronization constructs like signal/wait
and (counting) semaphores.
I guess it's time to get modern and add condition variables to
thread.c and threadmodule.c so we don't HAVE to write code like that
-- even if it's KSR's fault and not POSIX', I still agree that it's
bad writing style (even though it's lean and mean -- it doesn't
express what you want to happen).
That's all for now (logged in from a friend's home),
--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>
URL: <http://www.cwi.nl/cwi/people/Guido.van.Rossum.html>