Am 25.10.2016 um 15:30 hat Max Reitz geschrieben: > On 25.10.2016 10:24, Kevin Wolf wrote: > > 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, > > But it holds a lock on byte 2. > > > so the reader can start even though someone is writing to the > > image. > > It can't because it would try to grab an exclusive lock on byte 2 before > grabbing the shared lock on byte 1.
Apparently I failed to understand the most important part of the proposal. :-) So we have two locks. Both are only held for a longer time in shared mode. Exclusive mode is only used for testing whether the lock is being held and is immediately given up again. The meaning of holding a shared lock is: byte 1: I can't allow other processes to write to the image byte 2: I am writing to the image The four cases that we have involve: * shared writer: Take shared lock on byte 2. Test whether byte 1 is locked using an exclusive lock, and fail if so. * exclusive writer: Take shared lock on byte 2. Test whether byte 1 is locked using an exclusive lock, and fail if so. Then take shared lock on byte 1. I suppose this is racy, but we can probably tolerate that. * reader that can tolerate writers: Don't do anything * reader that can't tolerate writers: Take shared lock on byte 1. Test whether byte 2 is locked, and fail if so. Seems to work if I got that right. Kevin
pgpEjSuH0QATP.pgp
Description: PGP signature