Re: [9fans] QTCTL?

[Bakul Shah <bakul+plan9@bitblocks.com>]

> > 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.