[ECOS] Behavior of Scheduler?

[ECOS] Behavior of Scheduler?

[Alex Mathews]

Looking at the source for Cyg_Thread::sleep(), and then looking at the
source for Cyg_Scheduler::unlock() I see that it assumes that preemption
is always enabled for an application.  If an application disables
preemption (sched_lock = 1) and then a thread is put to sleep, 
sched_lock = 2 and then when coming out of the sleep routine sched_lock
= 1, and Cyg_Scheduler::unlock_inner() will never be called to switch to
another thread, because that only happens when (sched_lock - 1) == 0. 
This prevents the current thread from going to sleep and also prevents
another thread from running, because the changed state of the thread
isn't checked before deciding to invoke the scheduler.

I wanted to know whether this is the desired behavior, because I have
not seen this behavior with other RTOS's like VxWorks and QNX Neutrino.

If my above analysis is incorrect please let me know.  This analysis was
done on 1.3.1 source.

kernel/v1_3_1/include/sched.inl - Cyg_Scheduler::unlock()

Thanks.
-- 
Alex Mathews
CrosStor Software, Inc.
908-226-0100 ext 148
alexma@crosstor.com

Re: [ECOS] Behavior of Scheduler?

[Nick Garnett]

Alex Mathews <alexma@crosstor.com> writes:

> Looking at the source for Cyg_Thread::sleep(), and then looking at the
> source for Cyg_Scheduler::unlock() I see that it assumes that preemption
> is always enabled for an application.  If an application disables
> preemption (sched_lock = 1) and then a thread is put to sleep, 
> sched_lock = 2 and then when coming out of the sleep routine sched_lock
> = 1, and Cyg_Scheduler::unlock_inner() will never be called to switch to
> another thread, because that only happens when (sched_lock - 1) == 0. 
> This prevents the current thread from going to sleep and also prevents
> another thread from running, because the changed state of the thread
> isn't checked before deciding to invoke the scheduler.
> 
> I wanted to know whether this is the desired behavior, because I have
> not seen this behavior with other RTOS's like VxWorks and QNX Neutrino.

Originally the scheduler lock was intended to be a totally internal
mechanism to the kernel. Applications were meant to use mutexes,
semaphores etc. to handle synchronization since disabling preemption
is a somewhat sledgehammer tactic that we were not keen to see used
too much. Hence we were happy to make the scheduler lock somewhat
restrictive in its usage conditions, since only kernel code would use
it.

The main problem was that in order to make sleeping with the lock
work, the value of the scheduler lock has to become part of a thread's
state, rather than being a simple global value. This was considered too
expensive and was not strictly necessary in the original design.

Of course it is too useful to keep only for the kernel, so it crept
out into the APIs. However the restrictions remained - until now.

For somewhat unrelated reasons we have recently added the ability to
reschedule while the lock is non-zero. This is in the set of sources
that are scheduled to be in the next anoncvs release.

I should also add that while the scheduler lock functions as a
preemption inhibitor, it does more than that, for example it will also
inhibit delivery of DSRs. So running threads with it permanently
non-zero can serverely impact thread dispatch latency. (But I guess if
you are happy to disable preemption, then this may not be an issue.)

-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK