1. I hope you use fcntl() or lockf() [the same thing] to lock the file,
not flock(). flock() does local locking only.
2. You do *unlock* the file afterwards, don't you?
> p2 does the same as p1, but is started after the read of p1.
>
> i did read in "distributed systems" that it *** can *** take up to 3
> seconds for the client to receive update information (nfs cache latency).
In Linux 2.2, NFS locking with fcntl() or lockf() acts as a cache
coherency point. [This was added in 2.1.131].
You must not use the `nolock' option to mount.
So provided both clients lock the file around their access, there should
be no delay.
> i guess the upper system will work anyway (consider the update as "add 10
> to value") without losing counts?
If the locking is incorrect, it won't work. You'll lose counts.
Mail is easily lost for similar reasons.
If the locking is correct, it should work barring bugs.
[There is a rare race bug in NFS lock cache flushing whose fix I must
remember to send in]
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/