Semaphores in libc

[Luciano Rocha]

On Thu, Dec 31, 2009 at 04:23:33PM +0000, Paulo J. Matos wrote:
> Unfortunately it seems that my requirements are even more constrained.
> Just remembered that my servers are running NFS which seem to make
> semaphores useless since they seem to use /dev/shm.
> Thought about flock but wikipedia says:
> "Whether flock locks work on network filesystems, such as NFS, is
> implementation-dependent. On BSD systems flock calls are successful
> no-ops. On Linux prior to 2.6.12 flock calls on NFS files would only
> act locally. Kernel 2.6.12 and above implement flock calls on NFS
> files using POSIX byte range locks. These locks will be visible to
> other NFS clients that implement fcntl()/POSIX locks.[1]"
> 
> On the other hand one of the servers runs 2.6.16 and all the others
> are still in 2.4.21. As you can imagine I am not admin on these so
> there's no way I build new kernels.
> 
> Is there any solution for me? (I still have the mkdir solution pending
> until I confirm it is indeed atomic).

Well, according to the man page for mkdir:

      There  are  many  infelicities in the protocol underlying NFS.
      Some of these affect mkdir().

open("lockfile", O_CREAT | O_EXCL ...) also have problems, but the
manual page has a workaround:

       O_EXCL  is  only  supported  on NFS when using NFSv3 or later on
       kernel 2.6 or later.  In environments where NFS  O_EXCL  support
       is not provided, programs that rely on it for performing locking
       tasks will contain a race  condition.   Portable  programs  that
       want  to  perform atomic file locking using a lockfile, and need
       to avoid reliance on NFS support for O_EXCL, can create a unique
       file  on  the same file system (e.g., incorporating hostname and
       PID), and use link(2) to  make  a  link  to  the  lockfile.   If
       link(2)  returns  0,  the  lock  is  successful.  Otherwise, use
       stat(2) on the unique file  to  check  if  its  link  count  has
       increased to 2, in which case the lock is also successful.

-- 
lfr
0/0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-help/attachments/20091231/1b03f72e/attachment.sig>