public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Paul D. DeRocco" <pderocco@ix.netcom.com>
To: "eCos Discuss" <ecos-discuss@ecos.sourceware.org>
Subject: [ECOS] Scheduler locking and DSR context
Date: Wed, 16 May 2007 20:51:00 -0000	[thread overview]
Message-ID: <008001c797fb$c507d9c0$887ba8c0@PAULD> (raw)

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

                 reply	other threads:[~2007-05-16 20:50 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='008001c797fb$c507d9c0$887ba8c0@PAULD' \
    --to=pderocco@ix.netcom.com \
    --cc=ecos-discuss@ecos.sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).