[JSR308] Concurrency annotations on blocks

Doug Lea dl at cs.oswego.edu
Sat Feb 3 08:15:08 EST 2007


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've discussed this a bit with some Intel folks, so I think I can
explain. It meshes with one of my interests in seeing these styles
of annotations supported, which is more along  the lines of
"parallelism" (i.e., exploiting multiple CPUs for better
throughput) rather than "concurrency' (design for intrinsic
multi-threadedness).

It's a slightly long story that digresses from main focus of
this JSR, but here goes...

We are working on a new java.util.concurrent subpackage
supporting very lightweight parallelism that will, we
think, be very helpful in allowing people to exploit
32/64/+/way multicores that will soon enough be very common.
This is basically an overhaul of the work-stealing framework
I built and wrote about a few years ago, and is used, for example,
by the fortress folks as their main fine-grained execution
engine. (With some luck, preliminary versions of new package
should be available within a few weeks or months.)

While we are increasingly seeing very good parallel performance
using this framework, this alone doesn't suffice to make
it useful for most developers. Programming it directly
requires various refinements of a parallel-recursive
"Cilk" style that most people won't want to learn.

But we do know how to automate this for a large number
of common usages, including applyToAll for arrays and lists,
reduce, map-reduce, find-any, find-all, etc. These
have good performance even for surprisingly small
computations. So, we'd like to build in a
small suite of these.

Which leads to the question of how to expose them.
Right now, the only way people can express such things
is with clunky inner class constructions. For example,
if you'd like to sum the number of credits taken by all
the students in some list, using current draft APIs,
you'd write something like this to arrange the
corresponding map-reduce:

InParallel.reduce(students,
                   new Mapper<Student, Integer> {
                      public Integer map(Student s) {
                        return s.credits;
                      }
                   },
                   new Reducer<Integer> {
                       public Integer combine(Integer a,
                                              Integer b) {
                          return a + b;
                       }
                   });

Most people will think: "yuck!"

Better closure syntax may help, if the people working on such
things would ever stop fighting about it and get out a JSR :-)

But even the nicest closure syntax might still be too
foreign for people to regularly use. So it would be great to
have in place (via JSR308 efforts) something that would
allow us to additionally introduce annotation-guided program
transformations. This is full of various snags, but the idea
is that if someone wrote the much friendlier-looking...

   @ParallelAccumulator int sum = 0;
   @Parallelizable for (Student s : students) sum += s.credit;

... then there is some chance that a javac/jsr269 plugin could
do the rest. (Aside: One of the snags is that it is on the
edge of "altering semantics" that annotations aren't supposed
to do. For example, a parallelized version of a loop encountering
multiple RuntimeExceptions will throw one of them, but not
necessarily the one associated with lowest loop index. And behavior
in the face of unrecovered Errors (like OutOfMemoryError) is
completely different. I think we can probably get away with it
though. If not, maybe we'll just move the framework to X10 :-)

Note also that some of the primary JSR308 (and JSR305) annotations
(like ReadOnly) will probably be very useful here.

Questions, comments, and thoughts about all this would be welcome;
probably best off-list. It's far from a sure thing that
statement-level annotations will ever become used in this way even
if they are available. But I did want to clarify the underlying
interest from some of us concurrency/parallelism folks.

A further aside: Many (all?) of these applications of
extended annotations could instead be approached via IDE
plugins (imagine a menu item "please parallelize this loop").
Maybe this is even a faster path to success. But I find it
at best an admission of defeat if we cannot find a way to
express such things in the language proper.

-Doug
























More information about the JSR308 mailing list