Ah, well, all right. The trick isn't in fixing the old problem - the 
trick is in avoiding the new problem. Moving the call to #wait inside 
the ensured block certainly will fix the old problem of the semaphore 
not being signaled when the process gets terminated at the wrong point 
but how do you avoid the semaphore being signaled erranously because the 
process gets aborted after entering the ensured block and *before* we 
end up in #wait? (the same problem in reverse and just as bad)

The main trick here is that we really check for interrupts *after* 
executing primitives (and not before or during) which means that because 
(and only because!) wait is a primitive its call will not be interrupted 
(this btw, is one of the reasons why message tally sometimes associates 
a lot of time with a "wrong" primitive call - it cannot interrupt it 
before the primitive is executed and therefore sees the "wrong" method 
being run). Which means that if you were to change #wait to call a 
method #primitiveWait it would no longer be safe (possible interruption 
after the primitive check in #wait). It might be fun to try this out!

Hope this gets you the gist of it (it's really late here).

Cheers,
   - Andreas


Cees De Groot wrote:
> On 1/24/06, Andreas Raab <andreas.raab at gmx.de> wrote:
> 
>>Simply moving #wait inside the ensure'd block will cure the problem (for
>>very, very specific and nitpicky reasons that I'm not going to explain
>>in detail unless someone actually wants to know ;-)
>>
> 
> I do. I have a customer who is seeing error reports because of funny
> values turning up in collections that are supposed to be protected by
> critical sections. And the funny values turning up are very much the
> sort of stuff you get when that protection fails, so, yes, I
> desperately want to know about every possibility, no matter how remote
> 
> (apart from that, I'm a curious guy ;-))
> 
>