Author: Dave Gomboc
Date: 21:28:11 04/07/99
Go up one level in this thread
On April 07, 1999 at 16:54:32, Eugene Nalimov wrote: >Win32 synchronization API works fine in a "pessimistic" >situations - when you have one CPU, or when there is >heavy contention (i.e. several threads try to simultaneously >use the same protected resource). > >In the "optimistic" model - when there are several CPUs, and >all threads hold the resource only for a short time, it's >better to use low-level API like InterlockedExchange(), or >assembly code, and write your own primitives. The main idea >is to wait in a loop, hoping that the resource will be >released Real Soon Now. That approach is used in Crafty, >where only relatively small sections of code (tens of >instructions at most) are protected by locks. > >Even better results gives the intermediate approach - wait >in a loop for, say, 200 iterations, and if the resource >is not released yet (that means that one of the threads >is either do something serious under the lock, or suspended >by OS scheduler), "sleep" for a while. > >You can look at the file lock.h and take assembly language >versions of Lock()/Unlock() for MSVC for x86 and Alpha. I wrote >them for Bob. > >Eugene I was thinking that a good strategy would be: If the resource that you are waiting on is being used by a process that is blocked, then block, otherwise spin. Does that make sense? It assumes that one can tell which process has control of the resource. I am far from an expert in this area. Dave Gomboc
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.