Author: Bruce Moreland
Date: 00:37:31 02/01/99
Go up one level in this thread
On January 31, 1999 at 23:18:21, Eugene Nalimov wrote:
>Bob is right - if there is a chance that blocking thread
>will release a lock soon, it's better to loop and wait.
>There will be no cost of OS call, of thread swithing if
>lock is really busy, etc.
I am using MSVC 5.0. MSVC 6.0 produced code that is 10% slower for me, so I
haven't started using it yet.
If there is anything in the MSVC 5.0 documentation that says how critical
sections really work, I couldn't find it. I get the idea that something simple
is tried, and if that doesn't work, it does something extremely expensive.
But in my case, the simple thing should be the common case, and I still go like
a dog.
I tried something else:
INLINE void VLock(NPHASH nphash)
{
for (;;) {
PVOID pv;
register i;
pv = InterlockedCompareExchange(
(PVOID *)&s_argcs[nphash->dwKey & (ccsMAX - 1)],
(PVOID)1, (PVOID)0);
if (pv == (PVOID)0)
return;
for (i = 0; i < 256; i++)
;
}
}
There is very little documentation on "InterlockedCompareExchange", but I get
the idea that this might be what Bob's function does as well.
The idea in the above code is that "argcs" is now an array of integers,
initially set to zero, and how I do a lock is set the appropriate integer to one
if it is currently set to zero. I have a wait loop if I fail, because the thing
will probably get done soon.
This seems to only slow down my app by 5%, as opposed to 10%. I haven't tested
it to make sure that it is actually locking anything though, so perhaps I have
some bugs. I find my results to be somewhat strange, since I would expect a
Windows critical section to work just this way.
I think 5% is kind of weird, too. I'm doing a lot of stuff in my app, and I
find it hard to believe that the above really needs to be that high.
Do you have any idea what the best way under Windows (NT) is to do a
high-performance critical section lock, given that almost all of the time there
will be no contention for the lock (I'm using "critical section" in a generic
sense, I'm not talking about the Windows object necessarily).
I get the idea that the people who wrote some of the Windows functions made
assumptions about how they would be used, for instance that they would be used
in low-performance situations (a pefectly fine assumption in many cases, but
chess programs are not typical applications). Unfortunately, it's hard to know
what these assumptions are without guessing.
I'm asking this because you seem to know about this stuff. If you are too busy
to answer, no problem.
bruce
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.