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>
- 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:56:02 -0600
- Cc: <ecos-discuss at sources dot redhat dot com>
Ok, that makes sense. I thought you might have to use another condition
variable, but I wasn't sure if that was good practice. However, it
WOULD be bad practice to lock the scheduler until I'm done doing
something with the data!
My other solution of locking the mutex until the start of the next loop
would work too though right?
-----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 9:21 AM
To: Trenton D. Adams
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] cyg_cond_signal() without cyg_cond_wait ()
"Trenton D. Adams" <tadams@theone.dnsalias.com> writes:
> 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.
Exactly. The predicate that controls the behaviour of the consumer is
the "buffer empty" condition, not the state of the condition
variable.
>
> 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.
>
OK. The above code assumed that the buffer has enough room for several
chunks of data, and that the two threads were running at approximately
the same rate, so the buffer was just being used to smooth out any
jitters in the producer. If you need to exert some flow control on the
producer, then you need something like this:
Producer thread:
loop indefinitely
acquire/wait for data
lock mutex
while buffer full
wait for condition variable 1
copy data to buffer
update buffer pointers
signal condition variable 2
unlock mutex
Consumer thread:
loop indefinitely
lock mutex
while buffer empty
wait for condition variable 2
copy data out of buffer
update buffer pointers
signal condition variable 1
unlock mutex
do something with data
In this case the producer is halted while the buffer is full and the
consumer while it is empty.
--
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK