Subj : Re: thread control by mutex, predicates and conditions puzzle
To   : comp.programming.threads
From : Jomu
Date : Sat Jan 08 2005 03:36 am

I do not expect pthread_cond_wait (or any other blocked operation,
where other operations are as needed to be covered as pthread_*) to
return anything, I just sigwait() in signal handler for "resume"
signal. For this signal, I use pthread_kill(), of course.

My signaling thread uses sem_* family to communicate success of "pause"
from suspended thread to suspendor thread. When suspendor gets
confirmations from all suspended threads (sem_ count becomes equal to
number of signaled threads) it proceeds. Suspendor actions are covered
by general mutex which covers critical thread operations. When
suspendor completes it's task, it resumes all threads with same signal,
which all suspended threads are sigwait()-ing.

This is, of course, very general. For interested parties,
implementation (in Modula-3) is at
http://home.rstel.net/~dragisha/gc-pthread .

dd


Joseph Seigh wrote:
> On 7 Jan 2005 10:15:32 -0800, Jomu <dragisha@gmail.com> wrote:
>
> > There are signals which will get you out of pthread_cond_wait,
probably
> > all (I can't recall any exceptions). Your thread waiting on
condition
> > will get EINTR as result of pthread_cond_wait and there you can
handle
> > situtation. Of course, signal itself is supposed to be handled in
it's
> > handler and after getting EINTR it is up to your thread to lookup
state
> > changed by that handler.
>
> Most implementations will handle EINTR as a spurious wakeup but you
> cannot depend on that behavior.  The implementation is allowed to go
> back into wait.
> 
> -- 
> Joe Seigh

.