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

in reply to Re^3: flock on Windows : process killed while in critical region
in thread flock on Windows : process killed while in critical region

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.

Comment on Re^4: flock on Windows : process killed while in critical region

Replies are listed 'Best First'.
Re^5: flock on Windows : process killed while in critical region by BrowserUk (Patriarch) on Dec 16, 2012 at 11:04 UTC
Sorry, but unless you link some documentary evidence for that I'm going to say that you are flat-out wrong. Sleep( 0 ) has always relinquished the current timeslice of the thread on which it is called, from NT 3.5 upto and including Vista.... I do not have hands on knowledge of W/7/8, but I can find no evidence to support your premise there either. 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	[reply]
Re^6: flock on Windows : process killed while in critical region by bulk88 (Priest) on Dec 16, 2012 at 17:23 UTC
http://msdn.microsoft.com/en-us/library/windows/desktop/ms686298%28v=vs.85%29.aspx "ready to run" is the keyword, also http://blogs.msdn.com/b/oldnewthing/archive/2005/10/04/476847.aspx, https://www.allegro.cc/forums/thread/601451/827947#target, and http://books.google.com/books?id=I2vjPx-6qK0C&lpg=PA366&ots=0CpC6-TuCC&dq=%22choosing%20a%20processor%20for%20a%20thread%22&pg=PA367#v=onepage&q=%22choosing%20a%20processor%20for%20a%20thread%22&f=false.	[reply]
Re^7: flock on Windows : process killed while in critical region by BrowserUk (Patriarch) on Dec 16, 2012 at 18:28 UTC
So, I'll quote from your own first link: A value of zero causes the thread to relinquish the remainder of its time slice to any other thread that is ready to run. As I said `Sleep( 0 )` always relinquishes the remainder to the calling threads timeslice. Which is exactly all I stated. "ready to run" is the keyword, Sure, if the only thread ready to run is the thread that just ran, then is will be allocated a new timeslice immediately; but it still gave up its old one. And in the context of the OPs problem, it means that the task clean up will occur in a timely manner. This because, each time the scheduler is entered, any ready-to-run, but lower priority threads will have their priority temporarily boosted. Thus, the lower priority task clean up will quickly be boosted to a priority where it is selected in preference to the polling threads, thus the lock will be cleared, allowing one of the polling threads to acquire the lock and the system will continue. (I'll also remind you that I said "or just* sleep 0"*; ie. indicating that `sleep 0;` would suffice; not that it would be optimal!) 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 div	[reply] [d/l] [select]

In Section Seekers of Perl Wisdom