Semaphores in libc

[Luciano Rocha]

On Mon, Jan 04, 2010 at 02:05:01PM +0100, Petar Bogdanovic wrote:
> > 
> > Ok. If link($unique, $lockfile) returns success, then your process got
> > the lock. If it returns failure, but stat($unique) returns the number of
> > hardlinks > 1, then the link actually succeeded, but the client NFS code
> > may have for some reason got confused.
> 
> Or another thread got the lock in the meantime.

Hm, no. If stat($unique) returns an hard-link count greater than 1, then
the lockfile is the one created by the link().

> It's not that much
> about NFS as it is about the stat(2) call lacking value.  Whatever
> stat(2) returns, you can't rely on it since other things can happen
> between link(), stat() and your next step.

Well, there is a link to your unique (per process) file, so if it isn't
the lockfile, what is it?

> Why is the return value of link() not sufficient? (given a properly
> functioning NFS-client)

Maybe the standard is too lenient allowing properly functioning clients
work in mysterious ways? As you can see in the link I posted, NFS isn't
POSIX compliant.

-- 
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/20100104/40b0f922/attachment.sig>