False alarm. Outrigger uses a FastList for template management, as well
as for storing the actual entries. The late FastList adds all relate to
templates, and the last entry add is before the first write task starts
up. The writes are complete before the first read. This differs from my
original bug, which related to subjecting FastList to a mix of
concurrent adds and removes.
The bad news is that it looks as though the test is correct. I have
failed to break the current FastList implementation even running extreme
unit test loads overnight. The difficult aspects of FastList are now
delegated to java.util.concurrent.ConcurrentLinkedQueue, which I believe
is extremely well tested and reviewed.
That all means I need to dig into the guts of outrigger to find why some
reads are failing, instead of just looking at the reasonably simple
FastList and StressTest classes. :-(
Patricia
On 1/30/2011 10:33 PM, Mike McGrady wrote:
This is important. Good sleuthing
Sent from my iPhone
Michael McGrady
Principal investigator AF081_028 SBIR
Chief Architect
Topia Technology, Inc
Work 1.253.572.9712
Cel 1.253.720.3365
On Jan 30, 2011, at 10:28 PM, Patricia Shanahan<p...@acm.org> wrote:
Just that I'm seeing indications that the reads and writes may be getting mixed
up together, and wanted to be sure I'm debugging the right end of the problem.
On 1/30/2011 10:26 PM, Mike McGrady wrote:
I agree and am not sure why you have doubts?
Sent from my iPhone
Michael McGrady
Principal investigator AF081_028 SBIR
Chief Architect
Topia Technology, Inc
Work 1.253.572.9712
Cel 1.253.720.3365
On Jan 30, 2011, at 9:59 PM, Patricia Shanahan<p...@acm.org> wrote:
I wish it had been phrased in the same terms as the JLS. I know the write call completion
happens-before the call to the read method. I think that means the same as "the
write returns before the read commences" but I'm not sure.
Patricia
MICHAEL MCGRADY wrote:
There is this, which I assume you have already seen?
Operation Ordering
Operations on a space are unordered. The only view of operation order can be a
thread's view of the order of the operations it performs. A view of
inter-thread order can be imposed only by cooperating threads that use an
application-specific protocol to prevent two or more operations being in
progress at a single time on a single JavaSpaces service. Such means are
outside the purview of this specification.
For example, given two threads T and U, if T performs a write operation and U
performs a read with a template that would match the written entry, the read
may not find the written entry even if the write returns before the read. Only
if T and U cooperate to ensure that the write returns before the read commences
would the read be ensured the opportunity to find the entry written by T
(although it still might not do so because of an intervening take from a third
entity).
On Jan 30, 2011, at 7:42 PM, Patricia Shanahan wrote:
Suppose thread A writes an item to a JavaSpace, thread B attempts to read it,
and A's call to the space's proxy write method happens-before B's call to the
space's proxy read method. There are no transactions involved
Should the read always succeed?
In other words, should a happens-before relationship between two actions in a
client imply a corresponding happens-before relationship between the
corresponding actions in the actual space, without depending on transaction
semantics?
This question affects whether I'm working on a bug in outrigger or in one of
its tests.
Thanks for any information.
Patricia
Michael McGrady
Chief Architect
Topia Technology, Inc.
Cel 1.253.720.3365
Work 1.253.572.9712 extension 2037
mmcgr...@topiatechnology.com
