Re: [PATCH] for Review: SelectorImpl.wakeup() + Synchronization

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Mohan" == Mohan Embar <gnustuff@thisiscool.com> writes:

Mohan> One last thing: a 100% correct implementation of select()
Mohan> would have required atomically:
Mohan> - releasing selectThreadMutex's monitor
Mohan> - entering the select
Mohan> - then, reacquiring selectThreadMutex's monitor after the select
Mohan>   was done.

Mohan> My implementation doesn't do this and there can be race
Mohan> conditions which I've alluded to in the comments. I think it
Mohan> can be demonstrated, though, that the race conditions that can
Mohan> occur due to this approximation can occur with the ideal
Mohan> implementation with a slightly different calling sequence of
Mohan> the threads, so this approximation is probably okay.

As I understand it, in the Java model, "atomic" only has meaning in
two cases: (1) a single instruction of certain types is always atomic
(eg a store of an `int'), and (2) atomicity relative to a monitor that
is held.  Unless there is some other monitor in addition to
selectThreadMutex, the concept of selecting like that may not even
make sense.

Tom