This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: suspend/resume nesting
Thomas Koeller wrote:
On Wednesday, 21. May 2003 17:17, Nick Garnett wrote:
There are no deficiencies in the implementation of these functions,
they behave exactly how I intended them to.
As others have pointed out, what you are trying to do with
suspend/resume is way outside their designed purpose. Suspend is
intended to be a meta-control over the execution of a thread. When a
thread is suspended its sleep state is not affected and it may
subsequently be woken up although it won't execute until resumed.
But still I do not quite understand what the benefits of limiting the
suspend count to only positive values and the resulting asymmetry
between suspend and resume are, would you bother to explain that?
Because that's how it was designed... :-). A suspended thread can be
suspended multiple times, and resumed multiple times e.g. due to nested
calls in the kernel, but they must balance so that only the final resume
takes effect. But I'm fairly certain it may surprise people if it isn't
possible for the kernel to suspend a running task by calling suspend.
sus_tsk in the uITRON compatibility layer relies on it for conformant
behaviour for example.
But in any case, if it's what you really want to do, then the way to do it
is using the scheduler lock as sandeep described.
The intended users of suspend are things like debug monitors; "super
schedulers" that suspend and resume groups of threads according to
some higher level policy; or an exception handling mechanism that
suspends the offending thread an passes the event off to a handler
thread.
In all these cases, a thread other than the current one is suspended,
which is inherently dangerous because of its state being unknown. Or
isn't this the case? I cannot think of any safe use of suspend on a
thread other than the current one; am I missing something?
In such situations the state of the thread is unimportant. Does a
scheduler need to know the state of a thread when it does a timeslice? Not
all uses of asynchronous signals in POSIX are bad either for the same reason.
There are plenty of valid uses for suspend/resume. It's just that the way
you're trying to use it (without a scheduler lock at least) is not one I'm
afraid.
Btw., what about using Cyg_Thread::counted_sleep() and
Cyg_Thread::counted_wake()? I guess that would be a mistake as
well...
In one sense you can use whatever you want - that's a big plus with having
the source :-). You can change the way suspend/resume works yourself
too.... but the current behaviour isn't a bug and changing it would affect
semantics that people out there may be reliant on.
Jifl
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[ can rejoice because thorns have roses." -Lincoln ]-- Opinions==mine
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss