Author: Eugene Nalimov
Date: 13:54:32 04/07/99
Go up one level in this thread
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 On April 07, 1999 at 10:34:49, Bruce Moreland wrote: > >On April 07, 1999 at 01:29:30, James Robertson wrote: > >>Just out of curiosity, how does a critical_section do this? Is it something >>built into Windows? > >I don't know how they work. I know that when you try to lock a critical section >it will efficiently wait if the critical section is busy, but that the whole >general concept is kind of expensive, meaning that it is not something you want >to be doing every node. > >You can implement critical sections yourself via assembly code. There are >instructions like "cmpxchg", and instruction prefixes like "lock". > >If you are trying to control access to a fairly uncommon piece of code (a few >times per second), a critical section is great. If you use the piece of code >more often than this, you still may have a hard time beating a critical section, >I think, but you might wish you could. > >There are other primitives which are useful with threads. You can create an >"event" object, and you can tell a thread to wait until the event is triggered. >While it's waiting it will sit there in an efficient state. > >There are semaphores but I haven't had reason to use those yet. > >Mutexes seem to be heavy-duty things that you'd use to keep different >*processes* from accessing a resource simultaneously. That sounds pretty >expensive. > >I don't know what I'm talking about, so if someone wants to correct me that >would be fine. > >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.