This post originated from an RSS feed registered with Java Buzz by Jonas Bonér. Original Post: Semantics for a Synchronized Block Join Point Feed Title: grubbel Feed URL: http://docs.codehaus.org/dashboard.action Feed Description: Weblog of Jonas Bonér [jonas AT codehaus DOT org] Latest Java Buzz Posts Latest Java Buzz Posts by Jonas Bonér Latest Posts From grubbel

Currently you can for example pick out a call to a method that is declared as being synchronized and you can pick out calls to Thread:: notify()/notifyAll()/wait(). Meaning that being able to pick out synchronized blocks are the only missing piece left in order to completely control thread management and locking in Java. The actual bytecode modifications needed to make this work would be fairly simple, but capturing the correct semantics in a good language design would probably be a lot trickier.

In bytecode, a synchronized block is represented as a MONITOR ENTRY and a MONITOR EXIT bytecode instruction pair (however these are not required to be paired). The first natural approach would to let these two bytecode instructions be join points and treat them similar to field access and modification (PUTFIELD and GETFIELD bytecode instructions), meaning simply pick out (and intercept) this single bytecode instruction.

Just to clarify what I mean, here is an example of how the syntax for the above given semantics could look in the AspectJ pointcut expression language:

lock(Type t) && withincode(* Foo.bar(..)) && args(t)

unlock(Type t) && withincode(* Foo.bar(..)) && args(t)

synchronized(obj) {
    // body
}

MONITOR ENTRY // lock on obj
    // body
MONITOR EXIT

try {
    // a call to the around advice, which calls the lock manager
    aroundAdvice1(obj) --> myLockManager.acquire(obj); 

    // body

} finally {
    aroundAdvice2(obj) --> myLockManager.release(obj);
}

Since AspectJ (and AspectWerkz) already has limited support for the synchronized keyword by allowing calls to methods declared as being synchronized to be matched, let us take a look at the semantics for this join point.

Here's a simple method that is defined as being synchronized:

public synchronized void doStuff() { 
    // body
}

public void doStuff() { 
    synchronized(this) {
        // body
    }
}

execution(synchronized void *.doStuff())

call(synchronized void *.doStuff())

Using the execution pointcut, the above method body would be transformed to (pseudo code):

synchronized(this) {
    // the advice has option of invoking the original body
    myAroundAdvice(this) 
}

If we are using the call pointcut, the same code snippet would be transformed to (pseudo code):

...
// the advice has the option of invoking the original synchronized block
myAroundAdvice(this) 
...

I will not go into much detail about how these semantic differences should be expressed in the pointcut language here (this post is too long already). But for example, the last discussion would require the possibility of making a distinction between picking out a code block inclusively and exclusively (i.e. picking out the whole code block, or just the body of the code block), which could be expressed something like this:

// pick out synchronized block including the locking
block-inclusive(synchronized(Type t)) && withincode(* Foo.bar(..)) && args(t) 

// pick out only the synchronized block's body, not the locking
block-exclusive(synchronized(Type t)) && withincode(* Foo.bar(..)) && args(t) 

To sum up, the questions are: Do we want the power of intercepting the whole locking mechanism (but not the synchronized body), or is it better to follow the semantics we have for a synchronized method? Which approach addresses the use cases we want? Is the most intuitive? Is more orthogonal?

Thoughts? Comments? Ideas?