This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Condition Variables recap


"Trenton D. Adams" <tadams@theone.dnsalias.com> writes:

> Actually, I'm looking at the code for Cyg_Condition_Variable in
> mutex.cxx and according to it, it only dequeues ONE thread for
> wakeup/signal, and not more than that.  So I _BELIEVE_ that Gary was
> correct in what he said before.  Is this right?
> 

Be careful not to confuse the current implementation with the defined
behaviour. The current implementation will indeed only wake one
thread. But there are implementations, particularly in multiprocessor
systems, which may sometimes cause more than one thread to wake up.

Also, since the thread must re-aquire the mutex before continuing, it
may find that some other thread has invalidated the predicate before
it gets to run.

In general, whenever a condition wait returns, it must reevaluate the
predicate and decide whether to continue, wait again, or declare a
timeout (in the case of cyg_cond_timed_wait()). Returning from the
condition variable wait does not guarantee that the predicate is
either true or false. The usual way to make sure this works is to put
the call to cyg_cond_wait() into a loop that tests the predicate.

This is standard behaviour for any condition variable mechanism. The
POSIX standard requires condition variables to behave like this, and
we are following that as closely as possible.

Hope this makes things clearer.

-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]