On Sat, Aug 15, 2009 at 3:55 AM, John A. De Goes
<john@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).
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.