[Python-Dev] POSIX thread code

Martin v. Loewis martin@v.loewis.de
28 Feb 2002 08:57:32 +0100

"Tim Peters" <tim@zope.com> writes:

> Semaphores weren't defined by POSIX at the time this code was written; IIRC,
> they were first introduced in the later and then-rarely implemented POSIX
> realtime extensions.  How stable are they?

They are in Single UNIX V2 (1997), so anybody claiming conformance to
Single UNIX has implemented them:
- AIX 4.3.1 and later
- Tru64 UNIX V5.1A and later
- Solaris 7 and later
[from the list of certified Unix98 systems]

In addition, the following implementations document support for sem_init:
- LinuxThreads since glibc 2.0 (1996)
- IRIX atleast since 6.5 (a patch for 6.2 is available since 1996)

> > According to POSIX, they are found in <semaphore.h> and
> > _POSIX_SEMAPHORES should be defined if they work as POSIX
> > expects.
> This may be a nightmare; for example, I don't see anything in the Single
> UNIX Specification about this symbol, and as far as I'm concerned POSIX as a
> distinct standard is a DSW (dead standard walking <wink>).  That's one for
> the Unixish geeks to address.

You didn't ask google for _POSIX_SEMAPHORES, right? The first hit
brings you to


   Implementation supports the Semaphores option.

A quick check shows that both Solaris 8 and glibc 2.2 do indeed define
the symbol.

> They could be hugely better on Linux, but I don't know:  there's anecdotal
> evidence that Linux scheduling of threads competing for a mutex can get
> itself into a vastly unfair state.  

For glibc 2.1, semaphores have been reimplemented; they now provide
FIFO wakeup (sorted by thread priority). Same for mutexes: the
highest-priority oldest-waiting thread will be resumed.

> 	do {
> 		... call the right one ...
> 	} while (status < 0 && errno == EINTR);

Shouldn't EINTR check for KeyboardInterrupt?