Re: [ECOS] cyg_scheduler_lock and DSR's

[Bart Veer <bartv@ecoscentric.com>]

>>>>> "Jim" == Jim Bradleigh <jim.bradleigh1@btinternet.com> writes:

    Jim> Is the cyg_scheduler_lock() call not supposed to prevent
    Jim> DSR's from running?

Yes, and no.    
    
    Jim> I have a alarm, attached to the realtime clock which when
    Jim> activated posts a message to a custom queue system. This
    Jim> queue is also posted to by user land code..

    Jim> Pushes to the queue are protected by a mutex. Additionally
    Jim> around the mutex I have the cyg_scheduler_lock() and
    Jim> cyg_scheduler_unlock() to prevent the DSR posting a message
    Jim> whilst inside the mutex operation.

    Jim> However I`m seeing asserts stating the mutex is already
    Jim> locked. A quick breakpoint and I can see that the DSR is
    Jim> still being called even after the lock() function..

The purpose of cyg_scheduler_lock() is to lock the scheduler, as the
name implies. That means no other threads get to run while the current
thread is runnable (on single-processor systems anyway, it gets a bit
more complicated on SMP systems). A side effect of locking the
scheduler is that DSRs cannot be allowed to run, because a DSR must
run to completion and may manipulate the scheduler.

However, if a thread locks the scheduler and then tries to claim a
mutex that is already owned by another thread, things get more
complicated. A strict interpretation of cyg_scheduler_lock() would
mean that control cannot transfer to that or any other thread, so it
would never get a chance to unlock the mutex, so the system would be
deadlocked.

Instead the correct interpretation of cyg_scheduler_lock() is that it
locks the scheduler while, and only while, the calling thread is
runnable. If the current thread becomes no longer runnable, e.g.
because it tries to lock a mutex that is already owned or because it
tries to wait on a synchronization object, then the current state of
the scheduler lock is saved away, the thread suspends as normal, and
other threads are allowed to run again. DSRs are allowed to run again
as well - there is no reason not to and the alternative would
introduce other possibilities for deadlock. Once the other thread
releases the mutex and your thread gets to run again, the state of the
scheduler lock gets restored so that the subsequent
cyg_scheduler_unlock() does the right thing.

I do not know the full details of your custom queue system. I suspect
there is no need for the mutex lock at all - locking the scheduler
provides all the required inter-thread synchronization to prevent
concurrent access to the queue object, as well as blocking DSRs. If a
mutex is still required for some reason, you'll probably want to lock
the mutex first and then the scheduler, not the other way around.

Bart

-- 
Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
 >>>> Visit us at ESC-Boston  http://www.embedded.com/esc/boston <<<<
 >>>> Sep 22-23 on Stand 226  at Hynes Convention Center, Boston <<<<

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