Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Approaches to threading

Author: Anthony Cozzie

Date: 11:31:47 06/16/04

Go up one level in this thread


On June 16, 2004 at 14:18:21, Eric Oldre wrote:

>On June 16, 2004 at 10:34:20, Anthony Cozzie wrote:
>
>
>>
>>Here is what will happen (more or less, Operating Systems has never been my
>>strongpoint):
>>
>>CPU Snapshot:
>>Search thread - running
>>IO Thread - blocked, and in the idle queue waiting on input
>>Xboard - blocked, and in the idle queue waiting on a timer
>>
>>CPU gets timer interrupt
>>CPU transfers control to OS
>>OS notes that Xboard's waiting time has  finished and gives it the CPU
>>
>>CPU Snapshot:
>>Xboard - running
>>IO Thread - blocked, waiting on input
>>Search Thread - in the runqueue
>>
>>Xboard does its business and sends some command to your engine.  It then
>>finishes.
>>The OS notes that the IO thread now has data (its call can return) and transfers
>>it to the runqueue.
>>The OS's Scheduler then selects the IO thread over the Search thread because the
>>IO thread has been blocked longer.
>>
>>CPU Snapshot:
>>IO Thread - running
>>Search Thread - in runqueue
>>Xboard - blocked, waiting on timer
>>
>>At this point I think you have some idea of what is going on.
>>
>>One suggestion, if you are intent on doing threads.  The problem with the IO
>>thread is that it must receive commands from two places: the search thread and
>>Xboard.  This creates some very nasty issues to work out.
>>
>>Parallel programming is tough.  Write out your implementation *thoroughly* on
>>paper.  Think up the most *annoying* circumstances possible: What if the IO
>>thread gets a ping+move now+abort command sequence while the search thread sends
>>a game_over command?  Parallel programming is very difficult to debug because it
>>is nondeterministic: you might run the program again and the error won't occur.
>>Most importantly: MAKE SURE YOU RUN ON A MULTIPROCESSOR MACHINE.  Hyperthreaded
>>P4s are common enough that this shouldn't be that hard.  My first two threaded
>>implementations both worked fine on single processor machines, but broke down
>>completely on an MT machine.  My 3rd parallel implemenation worked on MP
>>machines, but had a few race conditions that only appeared in bullet.
>>
>>I'm in sort of the same boat right now, as I'm trying to write a parallel search
>>implementation, which is just as annoying and about 50000x harder :(
>>
>>anthony
>
>
>
>Anthony,
>thanks, that was a good description for me to get a handle on how things would
>work.
>
>I'm probably getting WAY ahead of myself, but I too would like to someday be
>able to support parallel searching. which is part of what is leading me to want
>to go the multi-threaded approach, this way i'd at least begin to get a handle
>on some of the techniques i'll need at that point. But your warnings are
>definately making me think twice about it.

That was one of my thoughts as well.  About two years ago ;)

>currently my only machine is a amd64 3200+, which of course is not mp. but i'm
>considering buying a new laptop, Which could be a hyper-threaded P4 and then be
>used for testing MP techniques. Do you know if the pentium M line uses HT
>technology?

No. It does not.

>Are there any specific issues you came across on the MP machine that didn't on
>the Single processor?
>
>Eric

If you want to learn about threaded programming, then I guess this is a good a
task as any.  The MP machine will have a larger number of race conditions that
can occur, because in a single CPU machine only one of the threads will be
running at any given time.  Also, I should say that I was very new to parallel
programming when I did my first implementation.  If I had to design it from
scratch now, I doubt I would need 4 tries :)

anthony



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.