On Friday 10 March 2006 09:32, Jan de Visser wrote: > > > Actually, stack2 looks very interesting. Does it "stay stuck" in > > > pg_queue_signal? That's really not supposed to happen. > > > > Yes it does. > > An update on that: There is actually *two* processes in this state, both > hanging in pg_queue_signal. I've looked at the source of that, and the > obvious candidate for hanging is EnterCriticalSection. I also found this: > > http://blogs.msdn.com/larryosterman/archive/2005/03/02/383685.aspx > > where they say: > > " > In addition, for Windows 2003, SP1, the EnterCriticalSection API has a > subtle change that's intended tor resolve many of the lock convoy issues. > Before Win2003 SP1, if 10 threads were blocked on EnterCriticalSection and > all 10 threads had the same priority, then EnterCriticalSection would > service those threads in a FIFO (first -in, first-out) basis. Starting in > Windows 2003 SP1, the EnterCriticalSection will wake up a random thread > from the waiting threads. If all the threads are doing the same thing > (like a thread pool) this won't make much of a difference, but if the > different threads are doing different work (like the critical section > protecting a widely accessed object), this will go a long way towards > removing lock convoy semantics. " > > Could it be they broke it when they did that???? See also this: http://bugs.mysql.com/bug.php?id=12071 It appears the mysql people ran into this and concluded it is a Windows bug they needed to work around. jan -- -------------------------------------------------------------- Jan de Visser jdevisser@xxxxxxxxxxxxxxxxxx Baruk Khazad! Khazad ai-menu! --------------------------------------------------------------
