I've found something I think is a problem in
com.sun.jini.test.impl.outrigger.matching.StressTest, but it does not
seem to be the problem, or at least not the only problem, causing the
test hang I'm investigating. It's difficult to test, so I'd like a
review of my reasoning. This is a question for those who are familiar
with the Java memory model.
Incidentally, if we went to 1.5 as the oldest supported release, this
could be replaced by an AtomicInteger.
In the following inner class, I think the methods reset and getCount
should be synchronized. As the comments note, the operations they
perform are atomic. My concern is the lack of a happens-before
relationship between those two methods and the increment method. As far
as I can tell, there is nothing forcing the change in the counter due to
an increment to become visible to a getCount call in another thread.
private class Counter {
/**
* Internal counter variable.
*/
private int _count = 0;
/**
* Constructor. Declared to enforce protection level.
*/
Counter() {
// Do nothing.
}
/**
* Resets internal counter to zero.
*/
void reset() {
// Integer assignment is atomic.
_count = 0;
}
/**
* Increments internal counter by one.
*/
synchronized void increment() {
++_count;
}
/**
* Returns current value of this <code>Counter</code> object.
*/
int getCount() {
// Returning an integer is atomic.
return _count;
}
}
