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]
Other format: [Raw text]

Re: Condvars usage for DSR/thread synchronization.


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


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