Re: [ECOS] Synchronization primitive for DSRs

[Andrew Lunn <andrew at lunn dot ch>]

On Thu, Nov 30, 2006 at 04:21:58PM +0100, Stefan Sommerfeld wrote:
> Hi
> >>
> >>I searching for a kind of mutex which also blocks a specific DSRs. 
> >>Mutexes
> >>doesn't work within DSRs, so the only way to share resources which are 
> >>used
> >>by a thread and a DSR is to use scheduler_lock() which blocks the whole
> >>system.
> >
> >Take a look at
> >
> >http://ecos.sourceware.org/docs-latest/ref/devapi-synchronization.html
> >
> >It suggests to use cyg_drv_dsr_lock()/cyg_drv_dsr_unlock(). This
> >should, it think, leave the scheduler running. However, in RTOSs, most
> >things are triggered by ISR, which naturally post DSR, and if you have
> >DSRs locked, events are just going to get queued up and never actually
> >processed. So think about deadlocks, try not to make any blocking
> >calls while you have DSR locked etc...
> >
> >Take a look at the serial device driver layers for examples of how to
> >use these locks.
> 
> It looks like the cyg_drv_dsr_lock() will lock all DSRs and so it will stop 
> multitasking and any other DSRs to run. That's not what I'm searching for. 
> Any other solution?

It should not stop multi-tasking. The scheduler can still run and do
task switches. But all DSR are blocked. So, for example, round-robin
will not happen, since that needs a timer tick, and so a DSR.  All
your device driver IO stops etc. But plain thread/thread interactions
should keep working.

There is no solution that i know of to stop an individual DSR from
running. There is no "DSR scheduler". 

It sounds like your DSR code needs refactoring and moving into a
thread. You then have all the usual synchronisation mechanisms. eCos
threads are low overhead, so there is no real need to have big DSRs.

        Andrew

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