how to make sem_post() async-signal-safe ?

[W. Richard Stevens]

sem_post() must be async-signal-safe, but none of the pthread_xxx()
functions need to be. I would guess many implementations of Posix
semaphores use threads and condition variables, so the question is:
how do implementations make sem_post() async-signal-safe ?

Rich Stevens

[Xavier Leroy]

The way it's done in LinuxThreads is to implement semaphore operations
with non-locking atomic operations (compare-and-swap) instead of
mutexes and condition variables.

Another option is to block all signals on entrance to sem_post(), and
restore them at exit, but this is expensive.

- Xavier Leroy
--
Valid e-mail address (without the underscores): Xavier.Leroy@i_n_r_i_a.f_r
This is a protection against junk mail. Apologies for the inconvenience.
Home page: http://pauillac.inria.fr/~xleroy/

[Dave Butenhof]

W. Richard Stevens wrote:

> sem_post() must be async-signal-safe, but none of the pthread_xxx()
> functions need to be. I would guess many implementations of Posix
> semaphores use threads and condition variables, so the question is:
> how do implementations make sem_post() async-signal-safe ?

While it would certainly be possible to implement POSIX semaphores using
mutexes and condition variables, remember that semaphores existed long
before POSIX threads. Many systems that implement POSIX semaphores did
so long before the POSIX 1003.1c standard was finalized (or
implemented).

Digital UNIX semaphores use special kernel functions for blocking and
unblocking (with proper semaphore semantics), after using hardware
"interlocked" (actually, "collision-detecting") instructions in user
mode to optimize the uncontended cases.

POSIX "pshared" mutexes and condition variables also need to block and
unblock inside the kernel. Although those functions aren't required to
be async-signal safe, there's no reason they couldn't be made so. And,
if they were, it would be possible to build POSIX semaphores using
pshared synchronization -- also resulting in an async-signal safe
sem_post. However, since you can't initialize a pshared mutex in private
memory, you'd have to implement sem_t using an external shared memory
area managed by the (realtime/thread) library. Would it be worth the
complication instead of continuing to use a "kernel semaphore"
implementation? Maybe; but there's no single answer.

/---------------------------[ Dave Butenhof ]--------------------------\
| Digital Equipment Corporation bute...@zko.dec.com |
| 110 Spit Brook Rd ZKO2-3/Q18 http://members.aol.com/drbutenhof |
| Nashua NH 03062-2698 http://www.awl.com/cseng/titles/0-201-63392-2/ |
\-----------------[ Better Living Through Concurrency ]----------------/