Re: Patch: Thread.holdLock implementation in java

[Archie Cobbs]

Dalibor Topic wrote:
> 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)

That description is ambiguous. It seems to me that "spurious wakeups"
are an artifact of certain programming practices, not the VM itself.

E.g., I don't see spurious wakeups listed in the four bullet points that
descripe the possible wakeup conditions, which seems like the more
normative list. The fact that they refer to books about good programming
practice would seem to bolster my point.

So at best, it's not clear what the "spec" is. I'd be conservative.

(In any case, it's not a big deal to me personally because JC already
implements this method natively).

> 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]

All of this is fine and agreeable but completely beside the point.
We're talking about what the specified VM behavior is, not what is
good programming practice.

> So I think all my implementation could do is to expose bugs in programs 
> where developers made flawed assumptions about the threading model. 

No, you'd create bugs in perfectly valid programs that rely on the
specified behavior like the class below:

    public class Event {

        private boolean triggered = false;

        public synchronized void waitFor() throws InterruptedException {
                if (triggered)
                        return;
                wait();
        }

        public synchronized void trigger() {
                triggered = true;
                notify();
        }
    }

-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com