This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Scheduler locking and DSR context
- From: "Paul D. DeRocco" <pderocco at ix dot netcom dot com>
- To: "eCos Discuss" <ecos-discuss at ecos dot sourceware dot org>
- Date: Wed, 16 May 2007 13:49:58 -0700
- Subject: [ECOS] Scheduler locking and DSR context
I'm perusing the eCos Reference Manual, (c) 2005, from eCosCentric. On p31,
near the end of the "Calling Contexts" section, it says:
"... threads can switch temporarily to DSR context by locking the scheduler.
Only certain kernel functions can be called from DSR context, although more
than in ISR context. In particular it is possible to use any synchronization
primitives which cannot block. These include cyg_semaphore_post,
cyg_cond_signal, cyg_cond_broadcast, cyg_flag_setbits, and cyg_mbox_tryput.
It is not possible to use any primitives that may block such as
cyg_semaphore_wait, cyg_mutex_lock, or cyg_mbox_put. Calling such functions
from inside a DSR may cause the system to hang."
As was recently mentioned here, each thread now has its own scheduler lock
count, and it is entirely routine for a thread to lock the scheduler inside
a device driver, and then call something like cyg_cond_wait to go to sleep.
It would seem to me, then, that locking the scheduler ISN'T the moral
equivalent of switching to DSR context. Is this just a bit of documentation
cruft from before threads were given separate lock counts? Or is there
something I'm missing?
--
Ciao, Paul D. DeRocco
Paul mailto:pderocco@ix.netcom.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