[JSR308] Concurrency annotations on blocks

[Brian Goetz]

Hi Steve!  Nice to see you again!

Thanks for posting a concrete, practical use case surrounding
annotations on synchronized blocks.

The case you offer fits into a more general category, systems where the
bytecode that comes out of the javac compiler is not the final code that
gets executed, but instead the input to the next stage of compiler.  In
that case, these annotations serve as #pragmas to the next-stage
compiler.  Another example in the same general category would be
specifying join points in an aspect framework.

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

I think this would be an overstatement.  The goal of the JUC library
(like most libraries) was to take common tasks that require potentially
difficult concurrency analysis, and provide a set of general-purpose
building blocks that are easier to use and require less analysis.  We
never expected that it would replace synchronization entirely; instead,
we hoped that it would replace _many_ instances of synchronization in
user programs, thus allowing programmers to write at a higher level of
abstraction and with less room for error.

The use of the concurrency libraries (or any thread-safe library
classes, for that matter) also follows a general principle that
synchronization should be encapsulated near where the data invariants
are specified.  Specifying it at too low a level risks atomicity
failures (e.g., using a volatile to implement a counter); pushing it up
to a higher level invites clients to "forget" to synchronize and
similarly invite race conditions.