[ECOS] condition variables and mutexes

[ECOS] condition variables and mutexes

[Trenton D. Adams]

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.

Trenton D. Adams
Extreme Engineering
#17, 6025 - 12 St. SE
Calgary, Alberta, Canada
T2H 2K1

Phone: 403 640 9494 ext-208
Fax: 403 640 9599

http://www.extremeeng.com

Re: [ECOS] condition variables and mutexes

[Nick Garnett]

"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

RE: [ECOS] condition variables and mutexes

[Trenton D. Adams]

That's great, thanks.  That clears a lot of conceptual problems I was
having! :)

-----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

RE: [ECOS] condition variables and mutexes

[Trenton D. Adams]

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

Re: [ECOS] condition variables and mutexes

[Nick Garnett]

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

> 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?

It is not good practice to rely on the semantics of the condition
variable signal operation to always wake up exactly one waiter. We
explicitly permit condition variables to generate spurious wakeups. So
it can never be guaranteed that when a thread awakes from the wait,
that the condition is still true, it must always check the state by
independent means.

Now, you might get away with it in your case, but as a general rule,
the loop should always be used.


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

Re: [ECOS] condition variables and mutexes

[Robin Farine]

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

> 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?

If you have exactly one producer and one consumer then you can a simple solution
that uses a ring buffer and a cardinal semaphore that counts the items in the
buffer. The producer waits for the semaphore and uses the buffer's in_index
while the consumer uses the out_index and signals the semaphore.

[...]

Robin

Re: [ECOS] condition variables and mutexes

[Robin Farine]

Heu, ahem ... correction:

The producer uses the buffer's in_index and *signals* the semaphore while the
consumer *waits* for the semaphore and uses the out_index.