Author: Scott Gasch
Date: 11:29:36 12/28/01
Go up one level in this thread
On December 27, 2001 at 18:31:20, Russell Reagan wrote:
>What is the advantage of using a spinning method of syncronizing vs. the
>blocking version? Are you supposed to do some extra work inside the spinning
>loop?
Yeah basically what Dan said. If you think about it though you'll see the
difference between the two. With both you have one thread trying to get a lock
that is already held by another thread. It can't proceed until the thread
holding the lock releases it.
On a single proc system the thread trying to get the lock is screwed. It might
as well give up its quantum and let the system schedule other threads on the
processor because while its running nothing else can be. That means the thread
holding the lock its waiting on won't get the processor time it needs to release
the lock while the waiting thread is sitting in the cpu spinning. Code like
this:
while (i_can_get_the_lock)
{
Sleep(0);
}
Might be the fastest on a UP system. The Sleep(0) call on win32 causes the
thread to give up its quantum. A quantum is on the order of about 20ms or so.
So this thread will check the lock and if it can't get it, give up the 20ms or
so it could have spend occupying the cpu needlessly. It will wake up again
whenever it gets rescheduled and repeat the process. Because it realizes that
if the lock isn't available now, it won't become available until another thread
gets the single processor.
On an MP system though you have the possibility that the guy who has the lock is
running right now in another processor. So spinning in the thread waiting for
the lock is a smart thing to do as long as you don't do it too long.
That's because while you spin in this CPU its very possible that the other guy
will release the lock... then you can obtain it and do something useful with it
before you are preempted by the system. So giving up your quantum with the
Sleep(0) call in this case is not smart -- especially if the lock is generally
only held for 1ms. If you'd just spin for 1ms you'll get to use 19ms or so to
do something useful. If you'd have given up the quantum in this version you
would waste the 19ms of work plus you have the latency of however long it takes
to get rescheduled.
If the lock is generally held for 500ms, though, then active spinning is a waste
because you could defer your quantum or block your thread and allow other
threads that have legitimate work to do access to the processor you would be
wasting while you spun. In the 500ms case, though, even passive spinning (where
you give up your quantum) might be a waste. In 500ms the waiting thread will
probably wake up a few times and check the lock uselessly. Maybe with a long
lock time like this it would be worth it to suspend the thread until the lock is
available and therefore not bother waking up and checking on the lock all the
time.
So you want to ask yourself a couple of things: how often, when a thread tries
to get this lock, does it find the lock is already held by another thread. That
is, what's the contention on this lock. Also, once a thread gets the lock, how
long does it generally hold the lock before it releases it. If you answer these
two questions you'll find the best method of waiting on the lock becomes
obvious.
BTW, your concept of the interlocked operations is basically right. Just read
the pages on MSDN pretty carefully and note the return values of the Interlocked
functions.
Dan's also very wise to tell you about isolating any platform specific stuff in
one module. It will make porting your code a lot easier. I put everything that
is not straight ANSI C in one file, system.c, and use conditional compilation to
pick code. That way my program builds on UNIX and Win32. And in order to port
it to some new platform you'd just have to modify system.c.
Scott
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.