river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <p...@acm.org>
Subject Re: Question about JavaSpaces functionality
Date Mon, 31 Jan 2011 13:46:06 GMT
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<pats@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<pats@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
>>>>> mmcgrady@topiatechnology.com
>>>>
>>>
>>
>


Mime
View raw message