[GRASS-dev] Re: what if: a new GRASS directory layout?

[Glynn Clements]

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 <glynn at gclements.plus.com>