[Seaside-dev] WAMutexTest>>#'testExclusion'

[James Foster]

I think I know what is happening here...

In VW and Dolphin, sending #'resume' to a process waiting on a  
semaphore gives an error (you can only resume a suspended process, not  
a waiting one).

In GemStone, sending #'resume' to a process waiting on a semaphore is  
silently ignored.

In Squeak, sending #'resume' to a process waiting on a semaphore lets  
the process become active (terminating the wait) even though the  
semaphore was not signaled! I think that this is the least desirable  
of the possible outcomes.

I'll update the test with something more portable.

James

Following is my sample code:

| sem1 proc1 sem2 proc2 sem3 value |
sem1 := Semaphore new.
sem2 := Semaphore new.
sem3 := Semaphore new.
proc1 := [
	sem1 signal.
	sem1 wait.
	"the process will resume if sem1 is signaled or (on Squeak) anyone  
sends #resume to proc1!"
	sem3 signal.
	value := 1.
] newProcess.
proc2 := [
	sem3 wait.
	sem2 signal.
] newProcess.
proc1 resume.
proc2 resume.
sem1 wait.
proc1 resume.	"this puts proc1 on the run queue even though sem1 is  
not signaled!"
sem2 wait.
value.


On Feb 6, 2009, at 2:39 PM, James Foster wrote:

> Julian,
>
> I got a failure on this test in GemStone because of a deadlock (no  
> processes are available to run). I've added lots of debugging code  
> to the test, but the upshot is that I think it was missing a signal  
> for semaphore1 (the test previously had two waits and only one  
> signal). I'm not sure how it could run on Squeak, but with the extra  
> signal it runs the same way on both Squeak and GemStone.
>
> Could you review and comment?
>
> James
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>