Author: Anthony Cozzie
Date: 07:34:20 06/16/04
Go up one level in this thread
On June 16, 2004 at 09:35:12, Eric Oldre wrote: >On June 15, 2004 at 18:19:59, Anthony Cozzie wrote: > >> >>My advice: just poll every so often. Threaded code is _tough_ to debug. I've >>had 4 different IO thread implementations in Zappa to date. I'm 99% sure I have >>it down now, but it really wasn't worth it. Humans are simply bad at parallel >>programming. >> >>anthony > >Anthony, thanks for the input, you are certainly making me think twice about >which way to proceed. I think i'll probably go the threaded route to start. >Since that is what i used in the VB.NET version of my engine. (but only because >i wasn't smart enough to figure out how to poll). But if things get tough i may >switch to polling. > >Also, do you know if there is any performance drain on the "thinking" thread if >you have 2 threads, but the other is only waiting for input? It's one of those >things I wouldn't want to find out after months of work. I always just assumed >most of the better engines used the threading technique, but i could be wrong. > >Eric 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
This page took 0.01 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.