Abstract

Prices of multi-core cpus are dropping and the move of multi-core processors to desktop machines doesn't stand still. There is a growing need of software developers to handle with concurrency-related problems in their application in order to improve the scalability. Today Moore's law is not applicable in the original sense as parallel computing increases. This idea growed up out of these reasons. Todays developers are all aware of the complexity of concurrent development
but cannot handle this complexity very well. In many cases it's not possible to detect such problems with static or dynamic code analysis which implies that developers need to take care of it. The main idea of
this project is not to solve concurrency problems but to help the developer to concentrate on the real hard things and eliminate the machine-solvable problems.

Concurrency-aware refactorings

Concurrency-related refactorings & quickfixes

Merge locks

One idea to improve the usability of refactorings in
due consideration of concurrency is to merge different
synchronized blocks into one. In the case the devel-
oper sees that two synchronize blocks (with the same
lock) could be merged to one single block to avoid
context switching. This fits into the category of quick
assists invoked by the user on demand. I don't see a
chance (at the moment) to detect such cases without
the knowledge of the dynamic behavior of the source
passage under stress. This is a typical case of what
I meant in the introduction. The developer has to
decide about the real problem and JDT should just
help him to make the code clean as he want it to be.

Split/stripe locks

Splitting or striping locks helps to reduce the size of
synchronized blocks. Splitting the lock at an specific
position should not be the problem with this as long
as the user provides informations where to split it.
Maybe it's possible with some research to come up
with some magic to have an automated partition of
the lock depending on the static analysis (at least
for trivial code
ows). I don't see \the magic" as
something which should definitely be implemented but
could be continually improved.

Convert between lock types

Everything is fine with the usage of the synchronized
statement. But projects are more and more migrat-
ing to J2SE 5 where new synchronization mechanisms
are available. As those should only be used if there
is a need for the advanced features of eg. Reentrant-
Lock there is no anchor for a compiler warning or
error. But we should consider to help the developer
by providing quick assists to transform the code be-
tween different synchronization styles. An example
is the convert between a synchronized block/method
and the usage of a ReentrantLock. This would help
the developer to not care about stuff like releasing
the lock in a finally block as this can be done by the
quick assist.

Introduce lock

Maybe the definition is a bit too vague - that goal
is not to find concurrency problems and introduce a
new lock or something like that. The usecase here
is rather simple. When we have cases where a lock
is needed due to a compile error like passing null as
lock to a synchronize statement, this refactoring has
it's big coming out. It should be very similar to the
\Introduce field" quick fix with some slight modifications
like a better guessed name, private and final
modifiers, initiating a new Object directly. These are
just some ideas which apply to my coding style but
need to be discussed again with a broader audience.

New compiler warnings

Avoid non-final locks

Lock not released in all paths

Usage of volatile arrays

Avoid global locks

Available features

Milestone 1 (available)

Here we will list all the features which are currently available in the plugin.

Compile warnings for non-final locks

Many developers have the need that every lock should be final to not change the lock inside the synchronized block. The plugins adds a new compiler warning which checks every used lock of synchronized statements wether they are final.

In order to quickly fix this warning, a new quickfix was introduced to react to this warning in order to turn the field into a final field.

Compile warnings for volatile arrays

Declaring an array field as volatile does not ensure visibility of its elements. Volatility cannot be manually propagated for arrays because array elements themselves cannot be declared as volatile.

Quick fix for null mutex

It happens from time to time that we insert null as mutex for a synchronized block which is not possible. JDT already marks this as error as you can see in the first screenshot.

In order to quickly fix this error, a new quickfix was introduced to introduce a new lock.

Milestone 2

Preference page for problem severities

As everyone has it's own style of development or is only interested in some of the compile checks, there is now a preference page which let's you decide if you want to see the problems as warnings or as errors. You can even disable the checks completely.

Milestone 3

Inlining synchronized methods

JDT does a great job with providing the "Inline method" refactoring. There is just one major issue that synchronization is completely ignored. In order to fix this, I'm working on a patch for the "Inline method" refactoring which allows you to inline synchronized methods and still having the proper synchronization in place.

Having a class like the following and inlining the method doSomethingWithLocks now correctly synchronized the inlined statements.

And the result:

Milestone 4

Milestone 5

Download

In order to have community feedback this project will release a new update site for every release. It consists of a set of plugins which extend JDT with new features.
There is no need to crazy patchin' you current installation - just add the update site to your P2 installer and install it.

Community Involvement

Getting the source

In order to have a look at the actual source code of the plugin you can use the team project set to import all relevant sources. Be sure to have Eclipse 3.4RC2 at least in order to compile the code.
Here is a short list of the involved plugins: