Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 3 Nov 2004 18:54:42 +0300
From:      Mike Makonnen <mtm@identd.net>
To:        Daniel Eischen <deischen@freebsd.org>
Cc:        John Baldwin <jhb@freebsd.org>
Subject:   Re: More mono + libpthread breakage..
Message-ID:  <20041103155441.GA1601@rogue.acs.lan>
In-Reply-To: <Pine.GSO.4.43.0411031019050.9924-100000@sea.ntplx.net>
References:  <20041103141914.GA2095@rogue.acs.lan> <Pine.GSO.4.43.0411031019050.9924-100000@sea.ntplx.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 03, 2004 at 10:24:10AM -0500, Daniel Eischen wrote:
> On Wed, 3 Nov 2004, Mike Makonnen wrote:
> 
> No, the problem has already occurred when sem_post() is called.  A signal
> occurs while blocked in pthread_cond_wait() but there is a race where the
> thread doesn't get removed from the CV queue then calls sem_post() which
> tries to requeue the thread on another synchronization queue.  Normally
> when a signal interrupts a pthread_cond_wait(), the thread should get
> removed from the CV queue before calling the signal handler but this
> isn't happening.

Ok, I misread the problem. However, even if my proposed solution doesn't help,
the heart of the problem is that while sem_post is signal-safe, none of the
pthreads API is safe. So you can call sem_post from within a signal handler,
but sem_post cannot expect to safely call a pthreads function from within
the signal handler; therefore, it has to find some other means of
synchronization.

While it is ok for a pthreads implementation to try to be more robust in
these kinds of situations it certainly isn't required by the standard. So
sem_post is relying on behaviour that is explicitly *not* guaranteed by
POSIX (hence it is in-breach of its signal-safe status).

I may be wrong, and welcome any corrections to my interpretation of
the situation.

Cheers.
-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
mtm@identd.net | Fingerprint: AC7B 5672 2D11 F4D0 EBF8  5279 5359 2B82 7CD4 1F55
mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon !



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041103155441.GA1601>