http://qs321.pair.com?node_id=743412


in reply to File Locking plus delete Lockfile question

A ++ for thinking about lock deletion. This is a basic concurrency issue that many programmers I've known fail to grasp. Some just ignore the problem since it may not occur often and it didn't occur during their tests. I've seen others waste a lot of effort writing and rewriting their code trying to somehow eliminate this race condition by sheer force of will.

In the general case you must know for sure that a lock cannot be accessed before you try to destroy it. As others have mentioned in general you need a higher level lock, or you need a special case (e.g. the machine is starting after a reboot and the app is known to have not started yet; the app is starting/completing and it knows it has no other threads running; etc). The special case may not work very well if your app is designed to run for weeks/months at a time.

  • Comment on Re: File Locking plus delete Lockfile question

Replies are listed 'Best First'.
Re^2: File Locking plus delete Lockfile question
by Anonymous Monk on Jun 03, 2013 at 05:37 UTC
    Hasnt anyone in the Perl community read the man page for POSIX unlink() function!! Perl' implementation is wrong. If it were right it would be easy to solve this issue.

      Hasnt anyone in the Perl community read the man page for POSIX unlink() function!! Perl' implementation is wrong. If it were right it would be easy to solve this issue.

      Seeing how perl just calls the system unlink function, that can't possibly be true