[JSR308] Concurrency annotations on blocks

[Steven Harris]

Hi,

I'm new to this list and this thread but as someone who works at  
terracotta(that's also a disclaimer)
I have some opinions on this stuff. We would definitely take  
advantage of painting blocks. Sometimes it's
things like giving a lock new properties as eu pointed out earlier  
(i.e. read lock, write lock etc)
other times it is as simple as whether one wants the lock to be  
cluster wide at all. It's not
just about synchronized blocks. Maybe this was already covered but  
things like static initializers
and any other code block could be useful as well. It would be quite  
nice to be able to just put an annotation
on it and make it auto-locked (our name for cluster wide  
synchronization instead of local).

An example of the first thing I was talking about is:

synchronized(a){ <-- I may want to make this an unshared lock
  some code...
  synchronized(c){ <-- this a read lock in the clustered world
   some code..
  }
  synchronized(b){ <-- this a write lock in the clustered world
   some code...
  }
}

I recognize this isn't something most people are used to but the
concept is quite useful for Terracotta.

Probably the hardest thing to do with terracotta config right now is  
to paint things that are more
fine grained than a method. I think annotations, with an extension to  
be able to support
blocks would be a great way to push past that limitation.

So with the above I'm guessing I'm just rehashing points that eu may  
have made. I briefly read through
some of this stuff and saw some value judgments on whether someone  
should use synchronization at all.
I'm curious about this. I've used the concurrent stuff some and find  
it useful for many tasks but maybe
due to my inexperience with it I haven't totally shifted to a mental  
model where synchronization is no
longer used at all. Is that what the latest wisdom is? No  
synchronization or critical regions?

Cheers,
Steve

-----

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.
 > Which they should be, if clients need that sort of functionality.
   Not necessarily. As Doug Lea pointed out, "that sort of  
functionality"
can be platform or environment-specific optimization. So, optimize and
clutter code with more heavy weight locking constructs may not be
appropriate for the sake of code simplicity.
 > Annotations aren't supposed to be used instead of good code.
   They aren't. Code would produce the same result without
post-processor. However in certain circumstances post processor can make
same code to run faster if it can use hints. That would help to make it
easy to writing multi threaded code as well as simplify coding for the
grid computing.

   I am not making this up and these tools already exist on the marked
(JBoss Cache, Terracotta), but they are suffering from the limitations
of the current metadata facility and have to workaround those  
limitations.

   regards,
   Eugene

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.csail.mit.edu/pipermail/jsr308/attachments/20070206/53720b5b/attachment.htm