Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

Re: flock on Windows : process killed while in critical region

by BrowserUk (Pope)
on Dec 13, 2012 at 12:27 UTC ( #1008654=note: print w/ replies, xml ) Need Help??


in reply to flock on Windows : process killed while in critical region

Now I wonder: Could there be cases, where a process gets killed while being in the critical region, BUT the lock is not being released (and therefore all other processes would be locked out forever)?

In a nutshell: No, that cannot happen.

However, if a process terminates whilst holding a lock, it may be some time before the OS gets around to releasing the lock -- dependent upon the availability of suitable system resources -- so attempts to acquire the lock should be programmed to retry, without tight loop polling, as a tight polling loop can itself be the cause of the unavailability of those system resources.

(For more info, see the "Remarks" under LockFile(Ex)(), which is the system call that underlies perl's emulation of flock() on Windows.)


With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

RIP Neil Armstrong


Comment on Re: flock on Windows : process killed while in critical region
Re^2: flock on Windows : process killed while in critical region
by rovf (Priest) on Dec 13, 2012 at 12:48 UTC
    Thanks, I'm relieved - this makes implementation simpler. As for no tight loop polling: I guess a sleep time of a couple of seconds between two calls to flock would not be considered tight anymore, i.e. it would be safe? Currently, we usually sleep between 3 and 12 seconds between polls.


    -- 
    Ronald Fischer <ynnor@mm.st>
      I guess a sleep time of a couple of seconds between two calls to flock would not be considered tight anymore, i.e. it would be safe?

      Even half a second or just sleep 0 (which causes the process to relinquish it's current timeslice) will ensure the OS gets processor time to clean up the dying process.

      The situation where things go wrong is when you have multiple processes all polling in tight loops, thus not giving the (lower priority) task of cleaning up the terminating process a look in.


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

      RIP Neil Armstrong

        On some Windows machines, Sleep 0 (the Win32 C call) has a habit of NOT releasing the time slot for efficiency reasons in the NT kernel to avoid excess context switches and per CPU cache locality (don't move threads or processes between CPUs unless high CPU usage). Sometimes until the timeslot expires (hardware interrupt), Sleep 0 will not release the timeslot and will just spin and the other thread remains frozen and the lock hasn't been released yet so your first thread is spinning in Sleep 0 burning CPU and the process seems deadlocked for many ms.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1008654]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (6)
As of 2014-07-25 23:47 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (175 votes), past polls