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 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

On Sat, Jul 4, 2009 at 10:02 AM, Mark Evenson<evenson@panix.com> wrote:

Mark Evenson wrote: […]

...

Anyways, I plan to commit the Gates implementation to trunk now.

Committed as [svn 12028][1].

Thanks! Both to you and Tobias. I followed up with a commit to set properties on all files recently added which didn't have the Id svn:keyword set. Please don't take offense; it's just administrative housekeeping. Bye, Erik.

On Sat, Jul 4, 2009 at 9:28 AM, Mark Evenson<evenson@panix.com> wrote:

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.

Well, if the timeout is a hard requirement (the thread MUST wait for at least x milliseconds), you would have probably needed to manually check that the timeout had really expired even without spurious wakeups, since wait() and sleep() do not guarantee any precision in respecting the timeout. If the timeout is not a hard requirement, you can probably live with the occasional (and very rare) spurious wakeup. Bye, Alessio