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.


Nick Garnett <nickg@ecoscentric.com> writes:
> Sergei Organov <osv@javad.ru> writes:
[...]
> > 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 );

Thanks for clarification, Nick. Now it does make sense to me.

> Of course this may be slight overkill when there is only one thread
> involved, but the mechanism was designed with device drivers in mind.

You are right, but it is an overkill even if there are multiple threads
involved while there is no data that are shared only by threads (i.e., all the
data constituting the condition are shared between threads and DSR). It seems
that the latter case along with single thread case are frequent enough to make
it worth to think about some optimizations.

Seeking for a most optimal primitive for DSR/thread synchronization it's
natural to look at condvar as a prototype. We just need to change mutex to
schedlock to get to the solution. This leads us to Yet Another Primitive
which is rather similar to the classic condvar but has "associated" schedlock
instead of mutex. Here "associated" means that corresponding 'wait' function
requires scheduler to be locked (similar to the classic condvar which 'wait'
requires associated mutex to be locked).

At least at first glance the implementation of such a primitive is rather
straightforward. It seems that it's enough to make a copy of current condvar
implementation and remove all operations associated with mutex from it along
with Cyg_Scheduler::lock() call in wait_inner(). Taking into account removing
of mutex lock/unlock in the using code we have eliminated 5 calls. Adding a
requirement for 'signal()' and 'broadcast()' to be called with scheduler
locked (that is the case when call is made from DSR anyway) we can also get
rid of scheduler lock/unlock calls in these two routines.

In addition, DSRs aside, if and when there are cases when schedlock is useful
for thread/thread mutual exclusion (for performance reasons), there could
also be cases when proposed schedlock-condvar is useful for thread/thread
synchronization.

Does anything of the above make sense to you?

BR,
Sergei.


-- 
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]