From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] QTCTL? In-reply-to: Your message of "Thu, 01 Nov 2007 10:28:48 EDT." <20071101142849.BA1A61E8C4C@holo.morphisms.net> From: Bakul Shah Date: Thu, 1 Nov 2007 09:59:43 -0700 Message-Id: <20071101165943.41E815B3E@mail.bitblocks.com> Topicbox-Message-UUID: e39239de-ead2-11e9-9d60-3106f5b1d025 > > Do you recall what the issues were? > > The main proposal I remember was to give out read and write > tokens and then revoke them as appropriate. The two big problems > with this were that it meant having spontaneous server->client->server > message exchange instead of the usual client->server->client > (a very large semantic break with existing 9P) and that once you > had granted a read token to a client the client could simply stop > responding (acknowledging the revocation) and slow down the > rest of the system. Thanks. > > Wouldn't something like load-linked/store-conditional suffice > > if the common case is a single writer? When the client does > > a "read-linked" call, the server sends an ID along with the > > data. The client can then do a "write-conditional" by passing > > the original ID and new data. If the ID is not valid anymore > > (if someone else wrote in the meantime) the write fails. The > > server doesn't have to keep any client state or inform anyone > > about an invalid cache. Of course, if any client fails to > > follow this protocol things fall apart but at least well > > behaved clients can get coherency. And this would work for > > cases such as making changes on a disconnected laptop and > > resyncing to the main server on the next connect. You > > wouldn't use this for synthetic files. This ID can be as > > simple as a file "generation" number incremented on each > > write or crypto strong checksum. > > This doesn't solve the problem of one client caching the file > contents and another writing to the file; how does the first > find out that the file has changed before it uses the cached > contents again? It can in effect find out if the file changed between two calls to the server. My thought was that there are many schemes for providing full consistency, each with its own strengths and problems so may be support for a specific scheme doesn't belong in 9p but if it provides "relaxed" cosistency of LL/SC, various full consistency schemes can be built on top of that. So for example if you read a lockfile and it says `free' you conditionally write `busy'. If the write succeeds you have exclusive access to the file being protected by this lockfile. But if the read says `busy' or if your conditional write fails, you try again. Cooperating user processes can set up any other scheme as well such as shared read exclusive write or a leased based one etc. If version number accompanies every read/write one can implement multi-versioned concurrency -- readers get a consistent version but writers can only write the "head" version. It would be nice to be able to implement that but I wouldn't want it builtin.