Lock convoys
- From: "chris noonan" <usenet@xxxxxxxxxxxxxx>
- Date: 8 Apr 2006 15:57:08 -0700
Back in the topic "Lock Free -- where to start" (October 2005),
I gave a quantitative example of how using a lock in a
multithreaded application can increase the number of
context switches the system suffers eleven-fold.
My analysis was of the form:
"Every time a thread is caught holding the lock at the expiry of
its scheduling quantum, the following bad things happen ..."
At the time, I couldn't extend the example to an application
in which thread switching is mainly I/O driven. Besides, eleven-
fold is enough to affect performance, but not to destroy it.
Recently I stumbled across this excellent article which
presents a more powerul mechanism:
http://blogs.msdn.com/sloh/archive/2005/05/27/422605.aspx
The gist of it is that certain synchronisation objects impose
fairness, for example only allowing contending threads to take
a lock strictly in the order in which they blocked on it. Then
the argument becomes:
"If a thread is ever caught holding the lock at the expiry of
its scheduling quantum, even once, the following bad things
happen evermore ..."
AFAICS, if two threads are involved, normal service is likely
to be resumed at the end of the next quantum. If more threads
are involved, the lock convoy persists indefinitely. The cost
of the convoy is one thread switch per lock access, which
could easily mean thousands of switches per quantum
(before taking into account the cost of the switches
themselves).
The example in the article is for Windows CE critical section,
and the article hints that the way critsec works is subject to
change. Does anyone know which other OS'es are likely to
show this behaviour?
Regards,
Chris
.
- Follow-Ups:
- Re: Lock convoys
- From: Joe Seigh
- Re: Lock convoys
- From: Maxim Yegorushkin
- Re: Lock convoys
- From: David Hopwood
- Re: Lock convoys
- Prev by Date: Re: pthread_create() doesn't start a new thread sometimes but doesn't return non-zero value on return.
- Next by Date: Re: pthread_create() doesn't start a new thread sometimes but doesn't return non-zero value on return.
- Previous by thread: Two threads, singleton read access problem
- Next by thread: Re: Lock convoys
- Index(es):
Relevant Pages
|
