This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: condition variables and mutexes
- To: "'Nick Garnett'" <nickg at redhat dot com>,<ecos-discuss at sources dot redhat dot com>
- Subject: RE: [ECOS] condition variables and mutexes
- From: "Trenton D. Adams" <tadams at theone dot dnsalias dot com>
- Date: Fri, 10 Aug 2001 08:52:53 -0600
Do I have to do the "while buffer empty" part if I've only got one
consumer thread? Because I figured the condition variable would only
get signaled once each round, and the buffer would never be empty except
for when the transmit thread is waiting on the condition variable. No?
-----Original Message-----
From: ecos-discuss-owner@sources.redhat.com
[mailto:ecos-discuss-owner@sources.redhat.com] On Behalf Of Nick Garnett
Sent: Friday, August 10, 2001 3:52 AM
To: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] condition variables and mutexes
"Trenton D. Adams" <tadams@theone.dnsalias.com> writes:
> Are the mutexes used with condition variables customarily used for
> synchronization with other consumer threads only, or does the producer
> thread use the mutexes as well?
>
> I would imagine that the producer thread would generally not use the
> mutex associated with a condition variable. I would think that if a
> mutex is needed, I should probably create a separate one for my use,
> right?
>
> Do I even care about the mutex associated with the condition variable
if
> I only have one consumer, and one producer?
>
>
> Here's my situation in particular.
>
> I've created a circular buffer that will hold three times the amount
of
> data required for each cycle. Cycles usually occur once every second.
> I've created three condition/mutex variable pairs for each of the
three
> slots in the circular buffer.
>
> Producer thread
> - fill the first slot of the buffer with the data, and signal the
> consumer thread (condition 1)
> - fill the second slot of the buffer with the data, and signal the
> consumer thread (condition 2)
> - fill the third slot of the buffer with the data, and signal the
> consumer thread (condition 3)
>
> Consumer thread
> loop indefinately
> - wait for signal 1
> - COPY data to another buffer
> - do something with data
> - wait for signal 2
> - COPY data to another buffer
> - do something with data
> - wait for signal 3
> - COPY data to another buffer
> - do something with data
>
> I need a way of making sure that the head pointer of the circular
buffer
> doesn't change to point to the next slot before the consumer thread
has
> copied it. I was thinking of using a mutex for this purpose.
>
Yes, a mutex is the right thing to use here. In a producer/consumer
situation they should normally be used in the following way:
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
The important points here are that neither thread should access the
buffer unless it has the mutex locked, and the consumer should base
its decision on whether there is data in the buffer by looking at the
buffer pointers, and not on whether the signal has occured or not.
Hope this helps
--
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK