This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Mon, Jan 04, 2010 at 04:29:50PM +0100, Petar Bogdanovic wrote: > On Mon, Jan 04, 2010 at 02:06:48PM +0000, Luciano Rocha wrote: > > 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(). > > If your shell example was no attempt at some kind of pseudocode then I > don't understand it. It's the implementation in shell-script of the text in the manual page. > If it indeed was a simplified version of a multi-threaded process, then > your assumption seems wrong. Hm, we're not talking of multi-threaded processes, but multi-processes only. If you want to add threads, then add an integer threadid to the unique filename. -- lfr 0/0
Attachment:
pgp00000.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |