On Mon, 2008-06-30 at 16:10 -0700, Andreas Raab wrote:
Norbert Hartl wrote:
What does this
<primitive: 19> "Simulation guard"
do?
It does nothing. It only indicates that the system will crash if that code ever gets simulated (usually due to atomicity violations).
Hmmm, looks quite confusing to me as the suspendingList is only one element in size the whole time. Hmmm...
Yeah, indeed. That is interesting. I don't have the time to look at this right now but it may actually be the solution to the problem. I think that a strategically placed #suspend in completeStep: may solve this problem. I'll have to think about this more ...
I had another look and I don't understand why the suspendingList has to be nil after the completeStep:. It is just a step over the wait. No signal happens nor any other cleanup. Or do you think completeStep: should somehow detect that it steps over a wait?
Anyway my conclusion is that the test in my first post can't work.
Not sure how you come to this conclusion. The test *doesn't* work but that indicates that a piece of the system is broken.
The test sets up a context with "sema wait". One step further it enters the critical: context (stepping over sema wait). The next instruction "top delete" sends terminate to the process. And Process>>terminate does a "suspendedContext home" which prevents the sema from being signalled (as the comment says). So the assumption of the test that the sema has to be signalled at that time is wrong.
Norbert
Any suggestions which side needs a change?
Simulating "out of" a semaphore wait is broken. The debugger test is still valid btw, since it illustrates the behavior in a practical manner.
Cheers,
- Andreas