Author: Eugene Nalimov
Date: 10:54:52 02/01/99
Go up one level in this thread
On February 01, 1999 at 03:37:31, Bruce Moreland wrote:
>
>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
Just look at the file lock.h from Crafty source. You will find
there 2 specialized assembly versions (for x86 and for Alpha),
as well as general one. General one is not the best one (it
lacks the waiting loop - it constantly calls
InterlockedExchange()), but it's actually never used. I wrote
both assembly versions, and you can freely use any of them.
Maybe it's better to slightly modify the Alpha UnLock():
insert "memory barrier" instruction (or call corresponding
AXP intrinsic) after assigning zero to the variable. (My
understanding is that with all current implementations that
zero eventually will be stored to memory, so lack of memory
barrier actually speed up the program, but you cannot be
sure about future processors).
Eugene
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.