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]

suspend/resume nesting


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


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