This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Behavior of Scheduler?
- To: eCos List <ecos-discuss at sourceware dot cygnus dot com>
- Subject: [ECOS] Behavior of Scheduler?
- From: Alex Mathews <alexma at crosstor dot com>
- Date: Fri, 18 Aug 2000 10:32:54 -0400
- Organization: CrosStor Software, Inc.
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