Re: [ECOS] Condition Variables w/o mutual exclusion?

[Jonathan Larmour <jlarmour at redhat dot com>]

Grant Edwards wrote:
> 
> Hi All,
> 
> I need a mechanism for one or more threads to block until an
> event happens inside a DSR.  Something like a flag bit would be
> perfect, but according to the table at
> http://sources.redhat.com/ecos/docs-latest/ref/ecos-ref.13.html#pgfId=1080419
> condition variables are the only mechanism usable from a DSR.

This does seem to be a religious issue. Personally I wouldn't object to
semaphores appearing. I'm not the only voice though.
 
> If I do have to use mutexes I don't need, I assume the client
> threads can use the sequence below:
> 
>   cyg_cond_wait(foo_cond);
>   cyg_mutex_unlock(foo_mutex);

Yes.
 
> Reading further in the section on condition variables, it says
> you should always use cyg_cond_wait() in a loop:
> 
>   The thread can only be awakened by a call to
>   cyg_cond_signal() or cyg_cond_broadcast() on the same
>   condition variable. When the thread is awakened, the mutex
>   will be reclaimed before this function proceeds. Since it may
>   have to wait for this, cyg_cond_wait() should only be used in
>   a loop since the condition may become false in the meantime.
>   This is shown in the following example:
> 
> What does "the condition may become false in the meantime"
> mean? Specifically, to what does "the condition" refer?

The normal times when condition variables are used - when waiting for some
sort of event (i.e. condition) to occur. You need to retest the condition
in case it happened twice, i.e. make sure that whatever the event signified
is still the case. More than one thread may have been woken up so that may
have "cleared" the condition.

Jifl
> This implies that the thread may be awakened spuriously when the
> event it is waiting for hasn't happened, but the first sentence
> says that the thread can only be awakened by a
> signal/broadcast. I don't understand why the loop is required
> -- under what conditions will the thread be awakened when it
> shouldn't be?

When some other thread has satisfied the "condition" first.

If your mutex is not really _used_ for protecting anything, you'll probably
find you don't care.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine