Re: [ECOS] cyg_cond_signal() without cyg_cond_wait ()

[Nick Garnett <nickg at redhat dot com>]

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

> I've been looking through the kernel sources for answers now that I
> understand a little more how eCos is laid out.
> 
> From what I've seen, it would appear that if I call cyg_cond_signal ()
> while there isn't a cyg_cond_wait () in progress, nothing will happen at
> all.

Correct.

> For example, I thought that MAYBE the condition variable would be
> signaled at a later time when cyg_cond_wait () was finally called.

If that were the case, it would be a semaphore and not a condition
variable.

> It
> looks like cyg_cond_wait () queues the waiting threads and
> cyg_cond_signal dequeues them.  But, it appears that cyg_cond_signals
> are not queued, correct?

Correct.

> 
> Based on that information, I should leave the condition variable's mutex
> locked until such time that I can loop again to call cyg_cond_wait (),
> correct?

Only if you are still accessing share data protected by the mutex. If
not you should release it.

> Should I be locking the scheduler at the end of the loop until
> the next loop has started?  If I don't, it's theoretically possible that
> a cyg_cond_signal () could occur before I get back to my cyg_cond_wait
> (), correct?
> 

If you are using cyg_cond_signal() without locking the mutex, then
that can happen. That is the price you pay for not using the mutex
"correctly". If you need proper synchronization between threads, they
must use the mutex. You should not be using the scheduler lock for
this. The state of the condition variable should not be treated as a
predicate. Its state can change unilaterally at any time. The true
predicate should be in data protected by the mutex, the condition
variable is just a signalling mechanism.


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