You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Patricia Shanahan <pa...@acm.org> on 2011/01/31 04:42:37 UTC
Question about JavaSpaces functionality
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
Re: Question about JavaSpaces functionality
Posted by Patricia Shanahan <pa...@acm.org>.
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<pa...@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<pa...@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
>>>>
>>>
>>
>
Re: Question about JavaSpaces functionality
Posted by Mike McGrady <mm...@topiatechnology.com>.
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 <pa...@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<pa...@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
>>>
>>
>
Re: Question about JavaSpaces functionality
Posted by Patricia Shanahan <pa...@acm.org>.
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<pa...@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
>>
>
Re: Question about JavaSpaces functionality
Posted by Mike McGrady <mm...@topiatechnology.com>.
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 <pa...@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
>
Re: Question about JavaSpaces functionality
Posted by Patricia Shanahan <pa...@acm.org>.
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
>
>
>
>
Re: Question about JavaSpaces functionality
Posted by MICHAEL MCGRADY <mm...@topiatechnology.com>.
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