Ivan Shmakov wrote: > > That can be handled by locking, and it can probably be done without > > significant changes to the API. > > Oh, I see that you mean fcntl () locks here. But weren't there > issues with them on certain OS' (W32) and FS' (NFS, in > particular with -o nolock)?
Win32 has locking primitives. And NFS loses for more reasons than just locking, e.g. rename() isn't guaranteed to be atomic. It is for good reason that NFS is widely believed to stand for "Not a File System" (as it violates a significant portion of POSIX). If you use NFS, either you ensure that locking works, or you essentially give up the ability to safely perform concurrent file access; this problem isn't limited to GRASS. > > The inventory system can prevent inconsistencies without any locking. > > However, there's still the potential for updates to be discarded if > > you don't have locking. I.e. if two process attempt to update a > > module concurrently, the update which completes first will be lost. > > Agreed. Though I'm not sure that the only reasonable way to > prevent this is to make any concurrent write access to fail. I'm not suggesting having concurrent access fail, just waiting until the operation is safe (e.g. F_SETLKW rather than F_SETLK). If modules are structured correctly (i.e. all support files are read in a burst before starting to read the data, or written in a burst after writing the data), both the probability of contention and the resulting delay will be minimal. In the case of multiple concurrent writes, you're bound to lose one of the two writes whichever mechanism is used. And if you want to block reads while a write is in progress (i.e. you specifically want the new data rather than just consistent data), you have to wait until the write operation completes. I'm primarily concerned with consistency, i.e. a read operation won't see a mix of data from multiple versions of a map, and it won't find that the map doesn't exist if it tries to read it at the moment that it's being replaced. IOW, ensuring individual read and write operations behave as an atomic transaction. If you want a complete read-process-write operation to behave as an atomic transaction, delays (or "busy" errors) cannot be eliminated (and there's also the potential for deadlock). > FWIW, the appropriate locking to a writable mapset could be > implemented without fcntl (). There are other ways to do it (e.g. lock files), but the OS' locking primitives are the simplest to use (no chance of stale lock files, no hacks to deal with NFS' non-atomicity, built-in deadlock detection, etc). -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
