This is the mail archive of the ecos-discuss@sourceware.org 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]
Other format: [Raw text]

correct handling of condition variables from DSRs


Hi,

the eCos docs say that condition variables can be signalled also from DSRs. Usually, in order to signal a change, the following code is required:

cyg_mutex_lock(&condition_mutex)
// ... modify the data
cyg_cond_signal(&condition_var);
cyg_mutex_unlock(&condition_mutex);


When doing this from a DSR, the mutex can't be locked, so I only can do:

cyg_cond_signal(&condition_var);


In order to receive the signal, usually I would:

cyg_mutex_lock(...);
cyg_cond_wait(...);
...
cyg_mutex_unlock();


Now this isn't synchronized with the DSR. The mutex docs say that cyg_scheduler_lock() has to be used, so it becomes:

cyg_scheduler_lock();
cyg_mutex_lock(...);
cyg_cond_wait(...);
...
cyg_mutex_unlock();
cyg_scheduler_unlock();

But the same protection has to be used when signalling from a thread, since otherwise the DSR could modify the data which are only protected by the mutex, right ?
So in order to signal the condition correctly from a thread I have to do the following:

cyg_scheduler_lock();
cyg_mutex_lock(&condition_mutex)
// ... modify the data
cyg_cond_signal(&condition_var);
cyg_mutex_unlock(&condition_mutex);
cyg_scheduler_unlock();


But since now all three participants (sender from DSR, sender from thread, receiver) are all synchronized using cyg_scheduler_lock(), do I actually still need the mutex at all ? Or can I simply ignore it ?

Bye
Alex

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


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