Re: [ECOS] suspend/resume nesting

[Eric Donnat <e dot donnat at silicomp dot fr>]

On Tue, 20 May 2003 19:20:00 +0200
"Koeller, T." <Thomas.Koeller@baslerweb.com> 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!
> 

I'm not sure that only such a patch is the solution to this issue.

I remember reading somewhere the suspend/resume were only to be used
to implement some kind of debugging tricks. If I understand your
point of view you are trying to use them in order to implement a
kind of synchronous thread RPC. The problem of such services is
much complex than exposed here because they could lead to priority
inversion issues when more than three threads are playing with them.

>From my previous experience, I found than implementing synchronous
mechanisms never requires suspend/resume, from the fact that
eCos is already exporting all what you need via existing synchronization
primitives (such as flags), thread priority control, and scheduler
control. IMHO, suspend/resume is like playing with fire.

-- 
Eric DONNAT

Silicomp Research Institute
195, rue Lavoisier
ZIRST-BP1
38330 Montbonnot-St-Martin (France)

http://www.ri.silicomp.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