[JSR308] Concurrency annotations on blocks

[Eugene Kuleshov]

Tom Ball wrote:
>>  I can't speak for Intel, but from my practice, one example also not 
>> mentioned in Java Concurrency in Practice is properties of the 
>> locking. For instance read or write lock, optimistic vs. eager 
>> locking. It is too coarse grained to express those on the method 
>> level only.
> Wouldn't checking the java.util.concurrent class type or method usage 
> tell you that?  I'm not arguing that those are important things to 
> check, but am just trying to understand what the annotation adds that 
> isn't already clearly expressed in the code.
  Probably. But only if those locks are used.

  I found that many developers still prefer to use synchronized blocks. 
So, construct like this:

  synchronized(mutex) {
    for(Item item : items) {
      ...
    }
  }

  can be either safe or unsafe, depends if code in the loop changes 
items or not. You can say that we can mark Item type as @Immutable or 
@ThreadSafe (if we allow annotations on local variables), but it won't 
have exactly the same meaning. Also, for there read lock it is allowed 
to have multiple readers, while eager write lock imply single owner.

  Another potential use case for block annotations is to express 
behavior of the  code on the callee side. For instance @Async annotation 
can be used if callee is not interested in the immediate result. Right 
now it would require to use concurrent executor API or some Aspect 
Oriented constructs to express something like that.

  I am well aware of the Sun's position on AOP, but it still worth to 
mention that annotations on code blocks would really help to manage 
caller side join points and allow to clearly mark the typed join point 
in the method code, instead of using combination of the method 
annotations for the caller and callee, which have certain limitations.

  regards,
  Eugene


>> Tom Ball wrote:
>>> Intel's comment with their vote intrigued me:  that annotations on 
>>> blocks and loops might be useful for specifying 
>>> atomicity/concurrency assertions.  I believe most Java programmers 
>>> don't have a full grasp of concurrency issues, and am interested in 
>>> any thoughts this group might have regarding concurrency assertion 
>>> ideas and what their annotations might look like.  We can start with 
>>> the ones in Java Concurrency in Practice, since I doubt anyone would 
>>> argue as to their importance.
>>>
>>> Perhaps the best way past our logjam (uh oh, I may get spanked again 
>>> ;-) is to come up with a conceptual set of cool assertion checkers 
>>> whose annotations can't be placed (or can't be placed optimally), 
>>> and then figure out how to remove those obstacles.  For me, the 
>>> reward from working on JSRs isn't have fat specs published (and I 
>>> doubt it is for anyone else), but their enabling of better 
>>> technologies.  Having a new set of assertion checkers waiting to be 
>>> written once this JSR is done is a strong motivator and focuser for me.
>>>
>>> Tom
>>>
>>
>>
>> _______________________________________________
>> JSR308 mailing list
>> JSR308 at lists.csail.mit.edu
>> https://lists.csail.mit.edu/mailman/listinfo/jsr308
>