Am 24.10.2016 um 20:03 hat Max Reitz geschrieben: > On 24.10.2016 12:11, Kevin Wolf wrote: > > [...] > > > Now, the big question is how to translate this into file locking. This > > could become a little tricky. I had a few thoughts involving another > > lock on byte 2, but none of them actually worked out so far, because > > what we want is essentially a lock that can be shared by readers, that > > can also be shared by writers, but not by readers and writers at the > > same time. > > You can also share it between readers and writers, as long as everyone > can cope with volatile data.
Sorry, that was ambiguous. I meant a file-level lock rather than the high-level one. If we had a lock that can be shared by one or the other, but not both, then two locks would be enough to build what we really want. > I agree that it's very similar to the proposed op blocker style, but I > can't really come up with a meaningful translation either. > > Maybe something like this (?): All readers who do not want the file to > be modified grab a shared lock on byte 1. All writers who can deal with > volatile data grab a shared lock on byte 2. Exclusive writers grab an > exclusive lock on byte 1 and 2. Readers who can cope with volatile data > get no lock at all. > > When opening, the first and second group would always have to test > whether there is a lock on the other byte, respectively. E.g. sharing > writers would first grab an exclusive lock on byte 1, then the shared > lock on byte 2 and then release the exclusive lock again. > > Would that work? I'm afraid it wouldn't. If you start the sharing writer first and then the writer-blocking reader, the writer doesn't hold a lock on byte 1 any more, so the reader can start even though someone is writing to the image. On the other hand, the writer can't keep an exclusive lock because it would block other users that can share the image. Kevin
pgpZdrCkQPr88.pgp
Description: PGP signature
