On 26.10.2016 13:01, Fam Zheng wrote: > On Tue, 10/25 16:57, Kevin Wolf wrote: >> 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. > > Does this mean I should change ImageLockMode to: > > * exclusive > * shared-write > * shared-read
Hm, those don't sound quite right, since it sounds as if you could mix
shared-read and shared-write. But you shouldn't be able to open an image
in shared-read lock mode when someone has opened it in shared-write lock
mode already.
It's difficult to come up with a clear but short name for shared-read
("exclusive", "shared-write", and "nolock" sound good to me). Maybe
"non-volatile" or "constant"? Or maybe "shared-only-read" would be clear
enough?
> * nolock
> * auto
>
> Where "auto" maps to exclusive for O_RDWR and shared-read for O_RDONLY?
Yep, that would be the correct mapping. Maybe later we can introduce an
auto-shared mode that maps to shared-write or nolock, respectively.
Max
signature.asc
Description: OpenPGP digital signature
