flock() Race Condiiton?

Keary Suska hierophant at pcisys.net
Fri May 10 14:08:32 CDT 2002


on 5/10/02 12:36 PM, cmiltonperl at yahoo.com purportedly said:

>> Is anyone aware of a possible flock() race condition that could cause two
>> processes vying for a lock to effectively lock each other out, and at the
>> same time, lock out any access to that file? I am trying to debug a rather
>> mysterious problem where a parallel processing system just hangs for some
>> reason.
> 
> According to 'perldoc perlfunc':
> Two potentially non-obvious but traditional flock
> semantics are that it waits indefinitely until the
> lock is granted, and that its locks merely
> advisory.  Such discretionary locks are more
> flexible, but offer fewer guarantees.  This means
> that files locked with flock() may be modified by
> programs that do not also use flock().

Yes, however, all of my processes use flock(). The issue is that for some
reason, all of the processes seemingly hang at the same time, and all of
them are accessing the same files. I did not mean to say that no process
could access the file(s), that is, they can as long as they don't use
flock().

Also, if there is no race condition, the first request for a lock should be
granted, and all others should wait for the lock to be released. As far as I
can tell, there is no reason that the lock shouldn't be released after being
granted (no apparent infinite loop conditions, or premature subroutine
exits). What I am wondering is if it is possible that two or more processes
request a lock simultaneously, and both receive a current locked condition,
so they wait, but the system establishes the lock, so all other processes
are forced to wait as well, indefinitely.

This is why I would like to be able to kick on the debugger while the
process is running, so I can see what is going on.

Keary Suska
Esoteritech, Inc.
"Leveraging Open Source for a better Internet"




More information about the Pikes-peak-pm mailing list