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 >>> >> >
