Peter Welch said
>>PS. do .NET/c# have semantic quirks like (d) and (e) above?
I'm unsure on this one. Sarah did a bit more reading on the locking mechanisms in .NET than I did, so I'll check up with her and see if anything like this came up, I am aware of there being some problems. .NET does have more locking mechanisms than Java, such as Auto Reset Events, which we used to implement our channels. These are basically binary semaphores, but they supposedly use native equivalents on a Windows machine, so any problems with the native model will most likely re-occur under .NET.
To implement the timeout on the Alternative, we used .NETs Timer object, which calls a method after a timeout period. This called method simply releases the main Alternative's lock. I'm unsure on how "accurate" the timeout period is, this would need further examination.
One thing to note, the interrupt exception does not have to be specifically coded for in .NET; therefore no try-catch when calling wait. If this exception were ever to occur and not prepared for, the system throws an exception and exits. Whether this is a good idea or not is up to debate.
Peter Welch said
>>Telling the difference between an early wakeup (e) and a spurious one
>>(d) is, I think, impossible - although we can guess. Early wakeups
>>happen all the time (unlike the spurious ones). I suspect it may be
>>to do with clock interrupts (on many JVMs) happening with only 10 ms
>>granularity ... so that it rounds the actual release to the nearest
>>10 ms, even if that's early?
Is this still true under Java 1.5? They added new a Nanosecond timer because of Java's lack of timing accuracy, and I had hoped they might sort out this problem too. Most likely wishful thinking on my part.
Dennis A Nicole said
>>The .NET methods for wait/notify are Wait/Pulse. From what I can
>>understand, Wait responds to Pulse and Interrupt, the latter by throwing
>>an exception. Monitor.Wait(Object) returns a bool. I don't think it can
>>ever return false. Does anybody know? False would mean we don't have the
>>Object lock... I also don't think that spurious wakeups can happen
This is good old OO at work. Monitor.Wait(Object) will never return false, it never returns until the lock is acquired. However, Monitor.Wait(Object, int) may do; int being a timeout period (milliseconds if I remember correctly). Therefore Monitor.Wait(Object) needs to return a value just to behave the same. Granted, it doesn't really have to return a bool, but you know how confusing it might be for developers if it didn't!!
Hope this helps.