Matt W. Benjamin wrote: > > ----- "Jeffrey Hutzelman" <[email protected]> wrote: > >> >> I'm not sure what you mean here. A FID+DV names a string of bits, >> period. > > It's in no way in dispute that, on the wire, "A FID+DV names a string of > bits." In order to analyze cache coherence, though (in a system which > considers caching), it is necessary to describe and reason about the views of > a file clients have cached. In a cache, necessarily, it is not sufficient to > consider the coherence only protocol messages--what we're reasoning about, in > addition, is a distributed system with state. > > Moreover, I think it's clear that in a cache, we're concerned about not only > the coherence of the distributed images of the cache, but, also, the > relationship of data that is cached with computations which may be in > progress on cached instances of the data. It is in this sense that I used > the term "useful" (or not useful). As Tom pointed out in side conversation, > this is not a gray area in computing science. "Basically [what] you're > asserting is the classical SMP mutual exclusion problem -- just having cache > coherence isn't enough to guarantee deterministic outcome of a parallel > application [sic, i.e., computation] without the use of synchronization > primitives" (tkeiser). The contents of an object after modification is no longer represented by FID+DV. It is now FID+DV-prime which represents a value that is not known to any other client or server. It is not part of a transaction. It can be done or undone. Until FID+DV-prime is stored to the file server, from the perspective of the rest of the world it does not exist. The transactions that matter for the purpose of analysis are the atomic operations that are performed with the file server and those are the ones that are represented on the wire.
If an application wishes to ensure that the data written locally is synchronized with the rest of the world prior to the StoreData RPC file locking must be used. Jeffrey Altman _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
