Concurrency annotations (again)
miguillo
be a JSR by itself?
(If you can't digest my examples, go down to the final question)
Introducing concurrency annotations implies reviewing all java's
current classes to say that e.g. :
- syncSet.iterator() "is guarded by" syncSet [with Set<Object> syncSet
= Collections.synchronizedSet(new HashSet<Object>()) ] (quite easy,
but it's a lot of line changes)
As suggested by Aaron Greenhouse thread:
http://groups.google.com/group/jsr-305/browse_frm/thread/d23818210240702d
concurrency annotations could be fine tunes:
- [ String func(String name) { return name.concat(" was")+" here" } ]
is "thread safe", why? this is the point to focus on. If I call
[ func(func(toto)) ] is it always thread safe? Yes, because it's
reentrant.
In resume: reentrantFunc1(reentrantFunc2()) = reentrantFunc3(). This
goes in direction of process algebra.
- Math.random() is not reentrant (you don't want it to be reentrant in
fact), but it is atomic and thread safe, but to know it, you have to
dig a bit, it would be nice to know it directly, but how?
Are those 2 last examples what would be "@Immutable method" in JSR-305
terminology?
In resume: reentrantFunc(atomicFunc1())=atomicFunc2(). This goes more
in direction of process algebra.
- Is a float operation really reentrant (given different processors
serializing informations through 2 computers, in fact, is serializing
reentrant?).
In resume: Side effect problems
What about more fine annotations in place (or inheriting) @ThreadSafe
like:
- @Reentrant : which seams quite easy for tools to confirm. Having a
good definition of @Immutable here is the big deal,
- @Atomic : correctly using @GuardedBy fields
- @... : I forgot some of "thread safety insurance"-cases, because I
don't figure out how to insure them, like @Deadlocksfree,
@Starvationfree,... Perhaps a @LockOrder could solve it or @PreLock
(you must take another lock before this one).
Final resuming question:
==================
could it be possible to introduce "process algebra"
"tags" (annotations) in Java language to have some good guarantee that
what you wrote is thread safe "by nature", like some functional
languages (this make me think about some @SideEffect annotation).
Could be a good challenge for some jdk7+ and a great advance. But
perhaps another JSR...
This idea is further than Aaron Greenhouse's one :
http://groups.google.com/group/jsr-305/browse_frm/thread/d23818210240702d
to fine tune annotation in a developer point of view, but in tools
points of view with recursive check for thread safety following
process algebra rules. E.g. One doesn't have to worry to annotate this
function:
double myRandom() {double toto=Math.random();return
Math.random()*2+3*toto;} because it is inheritable thread safe (only
local vars, atomic and reentrant calls, but it isn't neither reentrant
nor atomic, consider 2 times same seed with one time, form another
thread, a call to Math.random() in between).
PS: I apologize, English is not my mother tongue.
Keywords: annotations, process algebra
Brian Goetz
respect to capturing assertions about the consistency requirements and
guarantees in concurrent programs.
This is of course only my opinion, but I believe that there is a real
risk of "the perfect is the enemy of the good" in trying to capture too
much detail. The risk is that the annotation set is so large and
complicated, that people will either not use it, or use it incorrectly.
I think we agree that what we have now (nothing) is "too little". My
assertion is that there is a point that is "too much". So, our job is
to find "just right", or at least "close enough for V1."
Information is quantized, so the point immediately to the right of
"none" on the spectrum above is "one bit of information". While there
are numerous one-bit solutions, the most useful one bit of information
we can capture is a class-level @ThreadSafe annotation; this is a
statement of design intent, where the programmer says "I intend for this
class to be safe to be used concurrently without additional coordination
or synchronization."
So, let's take as our strawman the annotation set containing
@ThreadSafe. Clearly this is better than no annotations at all. It is
useful for capturing an important element of design intent. Moreover,
it requires very little additional thought on the part of the class
writer; when writing a class, you generally already know whether you
intend it to be thread-safe or not. So capturing it requires no thought
and a small number of keystrokes. The information is useful to the
clients of a class, for sure -- this is useful documentation. And
potentially might be useful to tools, a primary focus of JSR 305 (but
with only one bit of information, the tools won't be able to do all that
much more than they do with no bits of information.)
It is my belief that we can't add too many concurrency annotations
without undermining many of the benefits of the one-bit approach. The
more annotations there are, the more complexity, the more likely class
writers will use none of them. Its probably better to get 100%
penetration of @ThreadSafe than 5% penetration of "provably correct."
The other problem with the larger sets of annotations is that they still
end up being approximations. If we could construct a 30-annotation set
that asserted everything we might ever want to assert about concurrent
behavior, I might be more tempted. But I'm pretty convinced that the
30-annotation set is only an incremental refinement of the 3-annotation
set, and the 300-annotation set is only an incremental refinement of the
30-annotation set.
Curt Cox
concurrency annotations would be most useful to tools.
I realize that Brian is talking about concurrency annotations far
beyond Swing, however lack of Swing concurrency annotations are my
major pain point. In that arena, the more the annotations can spot my
mistakes (or verify their absence) ahead of time, the more I will use
them. Compile time is obviously the best time. For Swing, if the
needs of a good tool dictated the annotations required, I would adapt.
Does attacking the problem from the other side make it any simpler?
What is the highest number of concurrency annotations that anybody
from the tool community sees any value in?
Brian Goetz
> What is the highest number of concurrency annotations that anybody
> from the tool community sees any value in?
Right instinct, but we need to rephrase the question. I can think of
dozens of annotations (with possibly hundreds of variants) that can meet
the "any value" bar. We need to set the "pulls its own weight" bar
higher. But I agree that its reasonable to try and work it from both
sides and see what comes out of such an experiment.