This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
MLQ scheduler policy question
- From: Grant Edwards <grant dot b dot edwards at gmail dot com>
- To: ecos-discuss at sources dot redhat dot com
- Date: Tue, 2 Feb 2010 00:14:35 +0000 (UTC)
- Subject: [ECOS] MLQ scheduler policy question
Assume we're using the MLQ scheduler and there are a set of
threads all running at the same priority. The eCos docs
specify that the running thread won't be pre-empted by another
thread of the same priority unless the running thread
explicitly yields/blocks.
What isn't specified is what happens when a higher priority
thread becomes runnable, preempts one of our set-of-equals,
then blocks. Since the documentation doesn't specify that the
original thread will be resumed, I assume the scheduler is free
to choose any of the ready threads?
In practice is there a way to predict which of multiple ready,
equal-priority threads will be scheduled? [No, I'm not going
to depend on it, but I'm curious.]
The real-world case is a thread that calls send() on a TCP
socket. Some code was written under the assumption that the
thread that called send() would continue to run (after network
threads were finished) until it explicitly yeilded or blocked.
I don't think that assumption is valid, and calling send() may
cause a context switch (indirectly) to another equal-priority
task.
--
Grant Edwards grante Yow! We just joined the
at civil hair patrol!
visi.com
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss