Jeffrey Hutzelman wrote: > --On Friday, July 24, 2009 10:31:27 AM -0400 "Matt W. Benjamin" > <[email protected]> wrote: > >> Hi Hartmut, Felix, >> >> I see the point, it's not useful if it's only for decoration. It does >> feel intuitively right to have txid, if it could be used by a family of >> RPCs. Might make for cleaner interfaces for cancellation, abandonment, >> (not to mention futures--reversibility, delegation, ...)? > > Also note that multiple _reads_ can be going on at once, and you want to > be able to track those, too, so you can avoid letting anyone write while > there's a read in progress. > > The fileserver simply assumes that anyone who tries to extend or release > a lock is the caller that actually holds the lock, instead of using a > transaction ID. Let's not make the same mistake here.
I can't use the vnode->lock for this kind of locking, anyway, because the End-of-I/O-rpc wouldn't run in the same thread. So I have planned a counter for ongoing reads (write can only start if that came down to 0) a counter for waiters (to know whether End-of-I/O-rpc has to wake someone or just can free the struct) and, of course a writer field which contains the ip-address of the writing client or 0 if there is no write in progress. But all these are implementation details which have nothing to do with the AFS3 protocol and can be changed later if it seems appropriate. -Hartmut ----------------------------------------------------------------- Hartmut Reuter e-mail [email protected] phone +49-89-3299-1328 fax +49-89-3299-1301 RZG (Rechenzentrum Garching) web http://www.rzg.mpg.de/~hwr Computing Center of the Max-Planck-Gesellschaft (MPG) and the Institut fuer Plasmaphysik (IPP) ----------------------------------------------------------------- _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
