This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Condvars usage for DSR/thread synchronization.
- From: Nick Garnett <nickg at ecoscentric dot com>
- To: Sergei Organov <osv at javad dot ru>
- Cc: ecos-discuss at sources dot redhat dot com
- Date: 30 Jan 2003 13:57:50 +0000
- Subject: Re: [ECOS] Condvars usage for DSR/thread synchronization.
- References: <87r8avrlou.fsf@osv.javad.ru>
Sergei Organov <osv@javad.ru> writes:
> Maybe I'm missing something obvious, but I didn't find any discussion of this
> issue in the eCos documentation, so I'm asking here. How exactly a condvar is
> supposed to be used when signalling of the condvar is to be invoked from a
> DSR?
>
> According to the eCos documentation, a thread should execute the following
> code to wait on a conditional variable:
>
> cyg_mutex_lock( &mutex );
> ...
> while( condition_not_true )
> cyg_cond_wait( &cond );
> ...
> cyg_mutex_unlock( &mutex );
>
> In the case when 'cond' is to be signalled from a DSR (that is indeed
> explicitly allowed by the eCos documentation), 'mutex' seems to be of no use
> as operations on mutexes are not allowed from DSRs. Another mechanism should
> be used to protect 'condition' from simultaneous access by the thread and the
> DSR. Apparently 'cyg_scheduler_[un]lock()' is an appropriate tool for that.
> The thread should then execute the following code(?):
>
> cyg_scheduler_lock();
> cyg_mutex_lock( &mutex );
> ...
> while( condition_not_true )
> cyg_cond_wait( &cond );
> ...
> cyg_mutex_unlock( &mutex );
> cyg_scheduler_unlock();
>
> The resulting code looks rather strange as 'cyg_mutex_[un]lock()' calls seem
> to be redundant. On the other hand, we apparently can't remove them as
> 'cyg_cond_wait()' requires the mutex to be locked, I believe.
>
> Is condvar really supposed to be used this way?
>
The mutex is still useful to serialize multiple threads through a
device driver, for example. A better way of looking at how to
synchronize with a DSR would be this:
cyg_mutex_lock( &mutex );
{
// Only touch data shared by threads here...
cyg_scheduler_lock();
{
// Touch data shared with DSR here...
while( condition_not_true )
cyg_cond_wait( &cond );
}
cyg_scheduler_unlock();
// Only touch data shared by threads here...
}
cyg_mutex_unlock( &mutex );
Of course this may be slight overkill when there is only one thread
involved, but the mechanism was designed with device drivers in mind.
--
Nick Garnett - eCos Kernel Architect
http://www.eCosCentric.com/
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss