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


Hi Koeller,
   
               I am doubting whether anybody will go for your method. You
can go for synchronisation mechanism available in ECOS for this type of
requirements.

reji


On Tue, 20 May 2003, Koeller, T. wrote:

> Hi,
> 
> the implementation of CygThread::Resume() is such that if
> the thread to be resumed is not currently suspended, the
> attempt to resume it is ignored, because the suspend count
> is prevented from ever becoming negative. This creates a
> very undesirable behavior; I'd even go as far as to call it
> a bug, because it makes suspend() and resume() almost unusable.
> 
> Imagine two threads executing at different priorities.
> Thread A is currently executing, while B is suspended.
> A wants to wake up B, which then does some work and returns
> a result to A. So A invokes resume() for B and then suspends
> itself. B starts to execute, does its work, sets up the result
> that A is waiting for, calls resume() for A and suspends itself.
> 
> With the curent implementation, this scheme will only work if
> A's priority is greater than B's. If it's the other way round,
> B will run before A gets a chance to suspend itself, and B's
> attempt to resume A will have no effect, resulting in a deadlock
> when A finally runs again and calls suspend() for itself.
> 
> As I said, this kind of behavior is highly undesirable, as it
> makes the outcome of the above scenario dependent on the relative
> priorities of the threads involved, or even toally non-deterministic
> on SMP hardware. It also makes a difference whether the higher priority
> thread ever enters a wait state before it resumes its companion, or
> not.
> 
> The current implementation of the suspend/resume functionality is
> also rather different in this respect from other operating systems,
> at least the ones I have been using so far, which is not really
> surprising given the problems it creates. A 'correct' implementation
> would obviously allow negative values for the suspend count and implement
> proper nesting. I'd volunteer to provide a patch to this effect, if
> everyone agrees with my views. I do not expect severe incompabilities,
> but I may of course be wrong. So please send your comments, everybody!
> 
> tk
> ----------------------------------------------- 
> Thomas Koeller, Software Development 
> 
> Basler Vision Technologies 
> An der Strusbek 60-62 
> 22926 Ahrensburg 
> Germany 
> 
> Tel +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
> 
> 


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