Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Need a little help with multithreaded programming

Author: Robert Hyatt

Date: 21:05:00 12/27/01

Go up one level in this thread


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.

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.