Erik Huelsmann wrote: […]
I'm not particularly good at writing multiprocessing, or Java code. So please review carefully.
Tobias wrote this to support his version of a multi-threaded SLIME backend, and has proposed it for inclusion in ABCL.
When I get some time, I'll do some tests, but post the patch here in case it helps someone else out before that time or if their is any feedback.
Well, I had a look at it this afternoon and from my reading, Tobias does really understand how to write Java and ABCL/Java code. I didn't see any particular issues with the code, but any testing before committing will be highly appreciated, of course.
From my experience yesterday, I agree with your sentiments about the code (maybe some people are just born gifted!): the code works well, and smooths the threaded implementation of SLIME considerably (from a subjective point of view).
The one thing that bothers me is that apparently in Java, a thread in wait() can be woken up via so-called "spurious wakeups", i.e. no thread holding the object monitor that a wait() is called on has actually called notify() or notifyAll(). So, it is recommended (in the [documentation for java.lang.Thread.wait(timeout)][1]), that the following sort of code be used
synchronized(object) { while (<condition does not hold>) { object.wait(timeout); } }
[1]: http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html#wait%28long%29
but this seems seems like it would defeat the notion of specifying a timeout in the first place (i.e. as long as the condition did not hold), object.wait(timeout) would continue to be invoked). An explanation by someone of what I am not getting here would be helpful.
And there's the matter of testing, for which I would actually like to contribute unit tests that test the gates behavior. But coming up with tests for multi-threaded scenarios is a bit tough as well.
Anyways, I plan to commit the Gates implementation to trunk now.
Mark