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: gdb remote debug problem...running an ecos applicatio



Srinivasan Sriram <pet_jimmy@yahoo.com> writes:

> I'm trying out condition variables for the first time.  As per the
> reference manual, cyg_cond_wait releases the mutex (I don't have to
> explicitly use cyg_mutex_release(&mut)).

(and reclaims it - which may require waiting further - when the condition
 variable is signalled)
 
> But incase of cyg_cond_broadcast, I quote from the documentation - "Wakes
> all the threads waiting on the condition variable.  Each time a thread is
> awakened it will become the current owner of the mutex."

Yes, that's right.  But if there are many threads, they will wait in turn
for each other to release the mutex.  That's what mutexes do.

> But the threads waiting on the condition variables are not awakened until
> I explicitly release the mutex after cyg_cond_broadcast call.

Yes they are - and then they immediately sleep again waiting for the mutex
instead of the codition variable, because someone else holds the mutex.
The someone else happens to be the thread that did the cyg_cond_broadcast()
in your code, but that's your choice in the way you wrote your application.

> 1.
> Can anyone explain this? Why should thr2 release the
> mutex when cyg_cond_broadcast should automatically
> release it?                                 

No, cyg_cond_broadcast SHOULD NOT automatically release the mutex; there is
no requirement to own a mutex when you broadcast to the associated
condition variable.  Anyone can set or broadcast the condition variable.
A DSR can set or broadcast a condition variable asynchronously!
 
> 2. The ecos documentation says, I quote -
> 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:
> 
>   extern cyg_mutex_t mutex;
>   extern cyg_cond_t cond;
> 
>   cyg_mutex_lock( &mutex );
>   ...
> 
>   while( condition_not_true )
>   {
>    cyg_cond_wait( &cond );
>   }
> 
>   ...
> 
>   cyg_mutex_unlock( &mutex );
> 
> ------
> 
> WHY DO WE REQUIRE THE WHILE LOOP? ANY WAY THE CYG_COND_WAIT CANNOT
> PROCEED BEFORE IT OBTAINS THE MUTEX AND BROADCAST FROM THE PRODUCER AND
> OTHER THREADS?

It can proceed, but it might not want to - a condition variable does not
tell you things like "there is data in the buffer", it can only tell you
"there *might* be data in the buffer".  So you must check whether there is
data in the buffer before deciding to do the work to deal with that data.

In a simple application you might not need the loop.  But if you modify it
later you might get nasty bugs if you don't write this using a loop.

Suppose you have two threads both doing this but only one "thing" arrives.
Both threads awaken.  The first to get the mutex handles the "thing" and
releases the mutex.  The second thread wakes up and wants to handle a
"thing" but there is no "thing" there - because the other thread already
handled it.  So the second thread should just wait on the condition again.
That's what the loop does.

> ALSO COULD ANYONE EXPLAIN - WHAT IS THE VARIABLE IN
> THE WHILE LOOP. WHAT DOES IT TEST?

It's an example.  The "variable" should be replaced by whatever condition
you are waiting for.  If you are waiting for a buffer to contain data for
you to handle, you must write "buffp->length > 0" or whatever the correct
code is for your application.  (Ie. the "is there a thing there" test)

A condition variable is a way to wake up threads and pass hints about your
data structures.  It doesn't know anything about your data structures, only
you do, and only you can test whether your data structure truly needs
attention.

	- Huge


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