Author: Michel Langeveld
Date: 13:52:29 12/27/01
Go up one level in this thread
You understand already so much the only way to learn more is try something probably. I answered your questions trough your mail. 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. The best way it to prohibit you need it. And give each threads its own memory. An other approach in a chessprogram is to not care about dirty reads and lost updates. For example in a dual processor version of a chessprogram the hashtable doesn't need to be locked. >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. I made a chessprogram nullmover without mutexes at all. I don't know what you are trying to make but as long as you don't make you own GUI, don't make permanent brain or make a dual processor chessprogram the above is not really needed at all. It can bring a lot of insight of building software ofcourse. >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? IMHO it are somehow all the same things. 1) A critical section is a place where 2 threads can enter at once and this place must be reentrentable (as I described above in a chessprogram most of the time you can do without it. 2) Semaphore = method to protect shared memory (signals) 3) Mutex = design pattern to protect shared memory. >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 The thing you have to do to make your chessprogram SMP is to make the search reentrent. There are various approaches how this can be done. Locking is time consuming so the less locks the more knps you will have. Michel
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.