Date: Wed, 3 Nov 2004 11:11:19 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Mike Makonnen <mtm@identd.net> Cc: John Baldwin <jhb@freebsd.org> Subject: Re: More mono + libpthread breakage.. Message-ID: <Pine.GSO.4.43.0411031100020.10164-100000@sea.ntplx.net> In-Reply-To: <20041103155441.GA1601@rogue.acs.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 3 Nov 2004, Mike Makonnen wrote: > 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. The sem_post implementation, like all libc locking should, uses _pthread_foo() (single underscore). Our thread library implementations are suppose to treat these specially when needed. The single underscore versions signify that they are being used for the implementation and should be treated as critical regions (disable or defer signals if necessary). > 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. You're not wrong, it's just that our implementation should treat _pthread_foo() specially. We used the same pthread API because it is familiar, but it could just as well have been _libc_synch_obj_foo() or something. -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0411031100020.10164-100000>