Reputation: 29513
Since I am writing a profiler focusing on concurrency aspects, I am looking for a good artificial example using synchronization mechanisms in Java. My profiler makes visible some actions related to threading; for instance:
So what I am looking for, is a Java program which seems to be understood at first glance, but when executing it, you start to wonder about the results. I hope that my profiler might be able to detect what is going on in the background.
To clarify myself I give you an example, the book Java Concurrency in Practice by Brian Goetz gives "toxic" code examples which are used for learning reasons.
@NotThreadSafe
public class ListHelper<E> {
public List<E> list =
Collections.synchronizedList(new ArrayList<E>());
...
public synchronized boolean putIfAbsent(E x) {
boolean absent = !list.contains(x);
if (absent)
list.add(x);
return absent;
}
}
This is intended to be an extension of a thread-safe class, by the method putIfAbsent
. Since list
is synchronized, but putIfAbsent
uses another lock for protecting the state as the methods defined on the list.
The profiler could display the used monitor locks and to the suprise of the user (or not...) the user would see there are two possible monitor locks instead of one.
I don't like this example very much, but I wouldn't ask, if I had already a bunch of good examples.
I found out my question is similar to this: What is the most frequent concurrency issue you've encountered in Java? and Java concurrency bug patterns.
But they refer only to broken concurrent programs. I am also looking for thread-safe implementations, but where it still not obvious that they are thread-safe.
Upvotes: 17
Views: 2133
Reputation: 4158
See the The Java Specialists' Newsletter for a consistent stream of small Java puzzles, many of which should fit your testing needs.
Upvotes: 2
Reputation: 3245
I would recommend looking around (or asking the authors) for the IBM ConTest benchmark suite as it contains a number of Java concurrency bugs (unfortunately not large open-source programs). The good thing about this benchmark is that the bugs are already documented (type, and location).
If you want to find more programs I would recommend taking a look at some of the research papers in the area of software testing/quality of concurrent programs. They should indicate the sample programs they've used in their studies.
If all else fails you could try search on GitHub (or similar service) for repositories that contain the necessary concurrency mechanisms (i.e., synchronization). You might find a large amount of Java code that way, the only problem is that the bugs are not documented (unless you look for commit fixes).
I think these three suggestions will supply you with enough programs to test your concurrency profiler.
Upvotes: 1
Reputation: 12748
Dining philosophers problem is a classical concurrency example. This link has one possible solution and more can be found around the web.
As described in the first link this example illustrates quite many of the common concurrency problems. Please let your profiler show how many it can track!
Upvotes: 2
Reputation: 9955
How about this?
class ObjectReference {
private volatile Object obj = null;
public void set(Object obj) {
if (obj == null) {
throw new IllegalArgumentException();
}
this.obj = obj;
synchronized (this) {
notifyAll();
}
}
/**
* This method never returns null
*/
public Object waitAndGet() {
if (obj != null) {
return obj;
}
synchronized (this) {
wait();
return obj;
}
}
}
You could get null
from waitAndGet()
actually. See — Do spurious wakeups actually happen?
Upvotes: 3
Reputation: 26713
Have a look at the list of FindBugs bug descriptions, specifically those belonging to category of Multithreaded correctness (right table column).
Each of these bugs contain references on why a particular idiom is bad and how can it be solved.
Upvotes: 11
Reputation: 1142
I'd go back in time, like maybe seven years or more, and find some open source code from the era before java.util.concurrent. Just about anything that rolled its own concurrency is going to have some subtle bugs in it, 'cause concurrency is hard to get right.
Upvotes: 3