Talk:Lock convoy

Windows 2003 priority boost

Could Ionescu007 cite a reference for the Windows 2003 priority boost for threads being awoken by an event? I thought this was in Windows 2000, not just 2003. —Preceding unsigned comment added by Ritchiep (talk • contribs)

This section seems to be confusing two different changes that have been made for reducing contention issues. The priority boost is for solving priority inversion, not lock convoys. As far as I know, this has always been part of the Windows NT kernel, from 3.1 onwards [1], although specific improvements may have been made in Windows 2000 that I'm not aware of.

The change made in Windows Server 2003 SP1 is the removal of the fairness requirement for critical sections. Previously, it would always be the case that the thread that had been waiting the longest would get access to a released critical section. As a result, releasing a critical section that another thread was waiting for always involved waiting for the new owner to wake up (if they were sleeping) and take ownership. As you can imagine, if many threads are waiting for the section like this, then releasing it becomes a costly operation.

With Windows Server 2003 SP1, the fairness requirement is removed and it becomes possible for any waiting thread to get the critical section. This can reduce the time spent on releasing the critical section considerably, at the expense of increasing the risk for thread starvation. Source: Advanced Windows Debugging, p. 538-545. 82.95.254.249 (talk) 18:02, 9 February 2008 (UTC)

Actually, you are the one confusing the balance set manager's priority boosting with the other priority boosts in Windows. Windows has multiple other prioritiy boosts other than the ones you've mentionned, including boosting on I/O completion, boosting on completion of a window message wait, boosting on completing any dispatcher wait while inside the foreground process, as well as boosting when finishing a wait on an event or semaphore. This latter boost, until Windows 2003, was a boost of +1, hoping to help the waiting thread acquire the critical section and start using it. Unfortunately, in the scenario where the thread releasing the lock was, suppose, priority 10, and the thread acquiring the lock was priority 8, a boost of +1 would not make this thread the highest priority thread on the system -- the thread which released the lock would continue running until its time slice expired. In Server 2003 and later, the waiter thread is boosted to +1 of the setter's priority, so our acquiring thread would now be priority 11, and thus the highest priority thread on the system -- it would now get the CPU and be able to do work with the resource acquired.--Ionescu007 (talk) 16:20, 28 May 2008 (UTC)