On Sat, Aug 15, 2009 at 3:55 AM, John A. De Goes <j...@n-brain.net> wrote:
> On Aug 14, 2009, at 8:21 PM, Sebastian Sylvan wrote: > > But you can't! I can easily envisage a scenario where there's a link >> between two pieces of data in two different files, where it's okay if the >> data in file A is "newer" (in a versioning sense, not a timestamp sense) >> than the corresponding data in file B, but the opposite doesn't hold. So if >> you have another program writing that data it will write first to A, and >> then to B. The program reading this *must* then read the files in the >> correct order (B then A, to ensure the data from A is always newer or at the >> same "version" as the data in B). >> > > That's nonsense. Because what happens if your program reads A while the > other program is writing to A Depends on the file system. For example, the file could be locked so you would just block. Or the file system might be transactional. I used files as an example, the point wasn't to get bogged down in exact semantics of concurrent access - assume all reads/writes are atomic (or can be viewed as such from the apps POV) for the purposes of discussion. > , or reads B just after the other program has written to A, but before it > has written to B? This is precisely the scenario that would be legal in that case. You'd end up with data from A that's newer than B, which we said was okay, but for some app-specific reason the opposite is *not* okay. In order for you not to crash you *have* to make sure you read from B first, because otherwise you could read from A right before it's updated, and then read B right after both A and B have been updated which means B is now newer than A and your program goes boom. The point is that the ordering of reads are not arbitrary. > As I said before, you cannot make any guarantees in the presence of > interference, _with or without_ commuting. That's a separate issue. The problem is that if you *do* depend on outside "interference", then the sequence of operations matters. -- Sebastian Sylvan
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
