pthread_cond_wait() versus sem_wait()
Vitali Fridman
I'm looking for an expert advice.
We currently have our own implementation of semaphores with somewhat
different semantic then standard Posix sem_post()/sem_wait() family.
Specifically our semaphores can have not only positive but also
negative values (with a meaning of a resource "deficit") and some other
differences.
We currently implement this with our semaphore being a structure
with a counter, pthread mutex and pthread conditional variable.
This implementation works fine but there are a couple of
problems:
1. Semaphore operations don't work reliably from a signal handler
routines.
2. We would like to see better synchronization performance.
Talking about the first point, my current understanding is that
it's not safe to call pthread_cond_wait()/pthread_cond_signal()
from a signal handler. There is a discussion in the Posix 1003.1c
about this specific issue. They suggest using sem_post()/sem_wait()
in this case instead.
So I'm thinking of rewriting our library where our semaphore will
be a structure consisiting of a counter, mutex, posix semaphore
and may be a varible indicating how many threads currently blocked
on this semaphore.
My questions are:
1. Is it really forbidden to use pthread_cond_wait()/pthread_cond_signal()
from a signal handler?
2. What can I expect in terms of synchronization performance with
my new implementation based on posix semaphores relative to the
current implementation based on conditional variables? Will it be
likely better or worth?
I would like to get some sort of gerneric, platform-independent
answer, because we currently have implementations for two quite
different platforms (SGI Irix 6.2 and Concurrent) and in the SGI
case underlying implementation is very likely to change quite
dramatically in their next major OS release.
Thanks,
Vitali Fridman.
Ben Self
Just as a quick off the cuff response (i am too busy to look at the
reference document just now ;-).
Yes, It is not safe to call pthread_cond_XXX() calls from a signal
handler. More specifically the reults are *undefined* (i.e. not what
you want.)
pthread_cond_t is one of the lightest of synchronization objects. I
would be astounded to find any performance problems directly
attributable to them.
As a warning the POSIX semaphore routines are (In my experience) not
likely to portably perform better and are not available on every
platform that supports some variation of pthreads.
good luck,
--ben
Ben R. Self
bs...@opentext.com
www.opentext.com
Open Text -- home of Livelink Intranet
Dave Butenhof
Vitali Fridman wrote:
>
> 1. Is it really forbidden to use pthread_cond_wait()/pthread_cond_signal()
> from a signal handler?
You are, in fact, forbidden to use ANY pthread interfaces from within a
signal handler. That includes not only pthread_cond_wait and
pthread_cond_signal but also pthread_mutex_lock and
pthread_mutex_unlock.
The problem is that most useful functions deal with static state, and
therefore cannot be made to behave reliably when called with
"asynchronous recursion" -- that is, from a signal handler that was
invoked asynchronously while the function was already in progress. It's
not even trivial to make normally reentrant functions -- but to make
functions "interrupt reentrant" is really tough. In most cases, the only
practical solution is to disable signals while running the function.
(This is nothing new: there has always been a very limited list of
functions that are safe to call from within a signal handler. In
practice, most people ignore that list, and often get away with it, but
it's still officially unsafe & unsupported.)
Mutexes and condition variables are specifically NOT required to be
"interrupt reentrant", for a lot of excellent reasons. POSIX semaphores
are, on the other hand, required to have (limited) interrupt reentrancy;
in specific, it is legal to call sem_post() from a signal handler.
> 2. What can I expect in terms of synchronization performance with
> my new implementation based on posix semaphores relative to the
> current implementation based on conditional variables? Will it be
> likely better or worth?
It probably won't be better, but it'll definitely be "worth" while. ;-)
'Tis better to be correct than fast -- though 'tis nice to be both.
POSIX semaphores are specified in a way that allows an implementation to
avoid putting the full mechanism inside the kernel or blocking signals
on each call. In particular, sem_wait() calls that don't need to block,
and sem_post() calls that don't need to unblock, may be executed
entirely in user mode, without kernel calls.
> I would like to get some sort of gerneric, platform-independent
> answer, because we currently have implementations for two quite
> different platforms (SGI Irix 6.2 and Concurrent) and in the SGI
> case underlying implementation is very likely to change quite
> dramatically in their next major OS release.
As Ben Self replied, POSIX semaphores were part of a different POSIX
amendment (1003.1b-1993 realtime), and are controlled by a different
POSIX option than threads. Thus, you may well run into an implementation
of POSIX threads that doesn't support POSIX semaphores. However, without
them there is no "POSIX way" to create synchronization from a signal
handler, regardless of whether you're using threads.
/---[ Dave Butenhof ]-----------------------[ bute...@zko.dec.com ]---\
| Digital Equipment Corporation 110 Spit Brook Rd ZKO2-3/Q18 |
| 603.881.2218, FAX 603.881.0120 Nashua NH 03062-2698 |
\-----------------[ Better Living Through Concurrency ]----------------/