Use of NFS considered harmful

Voilà une piste intéressante

e. Delayed Write Caching
In an effort to improve efficiency, many NFS clients cache writes. This means that they delay sending small writes to the server, with the idea that if the client makes another small write in a short amount of time, the client need only send a single message to the server.
Unix servers typically cache disk writes to local disks the same way. The difference is that Unix servers also keep track of the state of the file in the cache memory versus the state on disk, so programs are all presented with a single view of the file.
In NFS caching, all applications on a single client will typically see the same file contents. However, applications accessing the file from different clients will not see the same file for several seconds.
Workaround: It is often possible to disable client write caching. Unfortunately, this frequently causes unacceptably slow performance, depending on the application. (Applications that perform I/O of large chunks of data should be unaffected, but applications that perform lots of small I/O operations will be severely punished.) If locking is employed, applications can explicitly cooperate and flush files from the local cache to the server, but see the previous sections on locking when employing this solution.

Source: http://www.time-travellers.org/shane/papers/NFS_considered_harmful.html

En résumé tu résoudrais ton problème en désactivant le disable client write caching au prix de performances intolérables. Je pense que la morale de l'histoire est qu'il ne faut pas utiliser NFS pour synchroniser des processus, mais une traditionnelle IPC (dans ton cas seules les sockets peuvent être considérées, j'opterai pour un seimple envoi de messages en UDP).