This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: cyg_cond_signal() without cyg_cond_wait ()


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]