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

["Trenton D. Adams" <tadams at theone dot dnsalias dot com>]

I'm not using cyg_cond_signal() without locking the mutex.  I lock the
mutex before calling cyg_cond_signal(), but this doesn't make my other
thread that's using cyg_cond_wait() get back to the cyg_cond_wait() call
before cyg_cond_signal () is called!

Here's the example you gave me.

Producer thread:
  loop indefinitely
    acquire/wait for data
    lock mutex
    copy data to buffer
    update buffer pointers
    signal condition variable
    unlock mutex

Consumer thread:
  loop indefinitely
    lock mutex
    while buffer empty
      wait for condition variable
    copy data out of buffer
    update buffer pointers
    unlock mutex
    do something with data

Now, with the example above, the producer thread could signal the
condition variable while the consumer thread is at "do something with
data".  This would cause the condition variable to never be signaled.
However, I assume that's one of the reasons for the "while buffer
empty"?  After all, it won't even bother waiting for the condition
variable again because the buffer isn't empty.

However, what happens if the acquire thread happens to be twice as fast
at getting the data as the consumer thread is at "do something with
data"?  This would cause the buffer to be filled twice in which case the
old data is now gone.


-----Original Message-----
From: ecos-discuss-owner@sources.redhat.com
[mailto:ecos-discuss-owner@sources.redhat.com] On Behalf Of Nick Garnett
Sent: Thursday, August 30, 2001 4:17 AM
To: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] cyg_cond_signal() without cyg_cond_wait ()
> 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