This is the mail archive of the ecos-discuss@sources.redhat.com 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]

Re: suspend/resume nesting


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?

>
> 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?

>
> 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.

I am only asking those questions to get a better understanding of
the design and the ideas behind it. To me it was not obvious at all
that using these functions for mutual thread sychronization is a
mistake, I was only following a design pattern I have successfully
used before. The intent was to exploit a mechanism that is in place
anyway, without having to maintain a synchronization object.

Btw., what about using Cyg_Thread::counted_sleep() and
Cyg_Thread::counted_wake()? I guess that would be a mistake as
well...

tk

-- 

Thomas Koeller, Software Development

Basler Vision Technologies
An der Strusbek 60-62
22926 Ahrensburg
Germany

Phone	+49 (4102) 463-390
Fax	+49 (4102) 463-46390

mailto:thomas.koeller@baslerweb.com
http://www.baslerweb.com 



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


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