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@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 ;-))