Re: [ECOS] suspend/resume nesting

[Nick Garnett <nickg at ecoscentric dot com>]

"Koeller, T." <Thomas.Koeller@baslerweb.com> writes:

> How would A release the scheduler lock while being
> suspended?
> 
> Anyway, this is not my point. Most responses to
> my original posting have been of the kind 'I am
> not using it, so I do not care whether it is usable
> or not'.
> 
> Now if somebody decides for himself that he does
> not want to use suspend/resume for one reason or
> another, that's perfectly fine for me. But I _do_
> want to use them, and as they are official API
> functions I should be able to do so. The alternative
> would be to remove those functions from the API
> (less preferable to me) or to warn  any users
> about the current implementation deficiencies
> (the least desirable alternative, I'd rather
> fix it).
> 

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.

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.

What you want to do is far better expressed using semaphores, or
mutexes or one of the many other synchronization mechanisms designed
for the purpose.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss