Re: Patch: Thread.holdLock implementation in java

[Dalibor Topic]

Hi Archie,

Archie Cobbs wrote:
> Dalibor Topic wrote:
>
> > I've implemented VMThread.holdLock in java. It's is probably quite slow, 
> > and wakes up the ocassional thread without much use, but hey, it's in 
> > java, so that's one less method to implement. OK to commit?
>
>
> Java in theory guarantees that threads are woken up only when
> notified via notify(), though not all VMs follow this (typically
> because they rely on pthread_cond variables, which don't provide
> this guarantee). So it your implementation potentially could produce
> bugs in otherwise correct programs.

I don't think Java's threading model guarantees that. The new Java 
Memory model spec explicitely allows spurious wakeups, from what I've 
seen by googling their mailing list.

In any case JDK 1.5's javadoc is very clear that spurious wakepus can 
happen. See
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html#wait(long)

Also check out doug lea's book on concurrent programming,2nd edition, 
section 3.2.3:
http://www.awprofessional.com/articles/article.asp?p=31539&seqNum=2

"Condition checks must be placed in  while loops. When an action is 
resumed, the waiting task doesn't know whether the condition it is 
waiting for is actually true; it only knows that it has been woken up. 
So, in order to maintain safety properties, it must check again.

As a matter of programming practice, this style should be used even if 
the class contains only a single instance of wait that waits for a 
single condition. It is never acceptable to write code that assumes an 
object is in some particular state when it resumes after a given wait. 
One reason is that such code could fail just because some other 
unrelated object invoked notify or notifyAll on the target object by 
mistake. (These are public methods defined on all objects.) 
Additionally, it is wise to avoid breakage in the case of spurious 
wakeups in which waits are released by the system without any explicit 
call to a notification method4. However, a more important consideration 
is that without re-evaluation, such code will start failing in peculiar 
ways if people define additional methods (perhaps in subclasses of your 
class) that also use waits and notifications for other purposes."

For another reference, see Joshua Bloch's Effective Java, Item 50:
Never invoke wait outside a loop. [1]

So I think all my implementation could do is to expose bugs in programs 
where developers made flawed assumptions about the threading model. 
Which is, well, their problem ;)

cheers,
dalibor topic

[1] I've got most of my references from 
http://www.cs.rug.nl/~wim/pub/whh241b.pdf