This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]