Subj : Re: thread control by mutex, predicates and conditions puzzle
To   : comp.programming.threads
From : roland
Date : Fri Jan 07 2005 02:58 pm

Jomu wrote:

> Of course it is not nonportable. POSIX defines signaling semantics, and
> it is as portable as POSIX 4a APIs.
> 
> dd
> 

Do you mean, a pthread_cond_wait _must_ wakeup on a signal on any
conformant pthreads implementation?

BTW.: In the meantime I found another solution to the original problem,
which will do without signals:

Given:

a  ... global state
ma ... mutex protecting global state

v  ... a variable
mv ... mutex protecting variable v
pv ... predicate about v
cv ... condition for pv changed

Now define:
pa ... predicate defined as following:
        bool pa() {
            lock ma
            evaluate predicate
            unlock ma
            return predicate value
        }

refc ... a reference (pointer) to a condition
refm ... a reference (pointer) to a mutex

Usage:
When it is time to wait on cv

     lock mv
     refc = cv
     refm = mv
     while(!pa && !pv) wait(cv, mv)
     evaluate a and /or v
     unlock mv

Another thread changes a, and signals:

     lock ma
     a = whatever
     lock refm
     notify_all(refc)
     unlock refm
     unlock ma

Another thread changes v, and signals:

     lock mv
     v = whatever
     notify_one(cv)
     unlock mv

Remark:
     notify_all is necessary, since we cannot know how many
waiters are there. The waiting and notifcation functions of
course should be wrapped into a function. Also the problem
of how to get access to the ref's has to be solved. But this
is a different matter.
Note that a cannot be changed without holding a lock to the
refm mutex. In this way it is implicitely used to protect
a as well.

Do you see any problems with this solution?

Roland

.