DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23159>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23159 [collections][PATCH] makes code easier to understand ------- Additional Comments From [EMAIL PROTECTED] 2003-09-15 11:10 ------- Yes, it would be good to have Stephen review the notify -> notifyAll change in add(). It looks like Buffer migrated from Avalon so if any of the the Avalon committers are around perhaps they could clarify the contract for Buffer.get(). My view is that get() is intended to be a query method which does not change the state of the Buffer being inspected. This is certainly the case in BoundedFifoBuffer where get() will return the same element for each invocation (unless invocations of add() or addAll() have been interleaved). If you accept the above behaviour of get() then the current version of TestBlockingBuffer.testBlockedGetWithAdd() is incorrect when it asserts that there should be at least one thread still blocked after an invocation of add(). In support of this, if one thread can invoke BoundedFifoBuffer.get() multiply and get the same result each time then one or more threads should also get the same return value i.e get() should not block when an element is available. The current version of testBlockedGetWithAdd() actually asserts the correct behaviour of a producer-consumer relationship where the producer is the BlockingBuffer and the consumers are the ReadThreads. (In fact it could be renamed to testBlockedRemoveWithAdd() and the ReadThreads constructed to use remove() instead of get() to make a valid test case.) To match this get() behaviour the JavaDoc in BlockingBuffer should change from BlockingBuffer decorates another Buffer to block on calls to the get method to wait until entries are added to the buffer. to BlockingBuffer decorates another Buffer to block on calls to the get and remove methods to wait until entries are available from the buffer. In summary the multithreaded test cases should assert these behaviours: testBlockedGetWithAdd: Two threads should block until one object is added then both threads should complete. testBlockedGetWithAddAll: Two threads should block until a singleton is added then both threads should complete. testBlockedRemoveWithAdd: Two threads should block until one object is added then one thread should complete. The remaining thread should complete after the addition of a second object. testBlockedRemoveWithAddAll: #1 Two threads should block until a singleton collection is added then one thread should complete. The remaining thread should complete after the addition of a second singleton. #2 Two threads should block until a collection with two distinct objects is added then both thread should complete. Each thread should have read a different object. I haven't made a patch for this as it needs Stephen's comments, as you mention. If I am utterly wrong about this I will be quite happy to have been educated! --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
