Author: Tony Werten
Date: 00:16:33 12/28/01
Go up one level in this thread
On December 28, 2001 at 00:05:00, Robert Hyatt wrote: >On December 27, 2001 at 14:25:09, Russell Reagan wrote: > >>I would like to try a multithreaded approach to writing my chess program, and I >>would like a little help in understanding some concepts. I understand the basics >>of multithreaded programming. I can start threads, setup data protection for >>data shared between threads, etc. Basically, I know how to use threads and I can >>implement them, I know how to implement data protection schemes (critical >>sections, mutexes, etc.) but I don't know the proper use of those data >>protection schemes. >> >>I have done a lot of asking around, posting on other message boards, gone to the >>library, and read some at my local bookstore, but I usually leave a little more >>confused than when I started. A typical "learning" experience goes something >>like this: I read about the need for data sharing protection, and then I read >>about the implementation of critical sections. So far so good. Then I move on to >>the next section and I read about mutexes, and I read about how to implement >>those. I understand everything that I've read, but I don't understand which data >>protection schemes I should use. In other words, I could implement a >>multithreaded application using critical sections, and I could do it using >>mutexes, and the other methods, but I don't know if I'm done after I get my >>program working with only one of those schemes. >> >>Are critical sections used for a certain problem, and mutexes used for another, >>and semaphores used for yet another? Or are they all an attempted solution to >>the same problem? And do I need to use more than one of these in my program, or >>will one of these methods solve the problem? And if one will do, are there any >>that would serve a chess program better than the others? >> >>From what I gather, on a single processor machine, using only one of these >>methods should work. But what new problems enter the scene on a multiprocessor >>machine and what solutions exist for those new problems? I am currently on a >>single processor machine, but I'd like to move to a multiprocessor machine in >>the future, so I'd like to have the framework *basically* in place to allow for >>a smooth transition. >> >>Thanks for your help. >> >>Russell > > >A critical section is simply a piece of code that updates something that is >_shared_ among several threads. And as a result, it must be executed by only >one thread at a time. I was wondering. If, when we write to the hashtable, we first write WORTHLESS to the hastable before writing the rest, and when we read, we read the flag last, shouldn't the impact of "wrong" tableentries be very limited ? (that is without locking ) cheers, Tony > >It is implemented by some sort of MUTEX mechanism. posix threads uses the >concept of a "lock" which is something you set at the top of a critical >section and clear it at the bottom. However, this "set" and "clear" operation >is done in a special way that guarantees that two threads can never look at the >lock and say "it is cleared, so I can set it and enter the critical section." > >posix threads calls them locks. In the Linux kernel, you will find things >called "spin locks" which is what I use in Crafty as they are much more >efficient. > >The main point is to recognize _every_ point where you update something that >is shared, and be _certain_ that you protect it with a lock to be sure that >only one thread does the update operation at a time... > >Next you have to understand the concept of "volatile" which is a variable >that can change its value spontaneously (from the compiler's perspective). >This is a case where another thread can change the value, and if you allow >the compiler to say "hey, I have a copy of this value in a register, I can >avoid the memory read completely" then you will get royally screwed. Volatile >variables can not be optimized like this, and it is _critical_ that you declare >such variables as "volatile" when needed to avoid getting optimized right into >the graveyard.
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.