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@digitalfairway.com
Baruk Khazad! Khazad ai-menu!
--------------------------------------------------------------
