This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: cyg_cond_signal() without cyg_cond_wait ()
- To: "'Nick Garnett'" <nickg at redhat dot com>,<ecos-discuss at sources dot redhat dot com>
- Subject: RE: [ECOS] cyg_cond_signal() without cyg_cond_wait ()
- From: "Trenton D. Adams" <tadams at theone dot dnsalias dot com>
- Date: Thu, 30 Aug 2001 09:04:13 -0600
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