Author: Jon Dart
Date: 08:04:40 12/31/99
Go up one level in this thread
As a couple of posters said, multithreading is the way to go here, but it is not simple to implement. Besides the locking and synchronization issues, there are some other gotchas. If you're on Windows with MFC, you need to keep your message pump going or your UI will lock up. This means that generally you don't want to do a WaitForSingleObject in the OnCommand function (Maybe you could make this work but I had a lot of problems when I was doing this). However, there are going to be a lot of cases where you need to stop the search in progress and then do a command. The most common case is when you're pondering and the user makes a move. Arasan deals with this by having a queue of pending commands. When it needs to stop the search, it puts the command that stopped it on the queue. Then it sets a flag to terminate the search. Then when the search thread ends, the search class makes a callback and the callback executes any pending commands (by calling PostMessage). See addToQueue, removeFromQueue, and OnSearchComplete in arasavw.cpp. It is probably simpler to run the UI and GUI in separate processes like Winboard does, although you will still hit some of the same issues on Windows. The X Window system on UNIX has a nice call to put external events (like a socket read) into your event queue along with Window events. --Jon On December 31, 1999 at 05:20:25, Tom Kerrigan wrote: >Let's say your program is thinking on the opponent's time, and the opponent >makes a move. You obviously can't just call the makemove() function in your >engine to enter the move, because the engine is in the middle of a search and >it's not on the right position. How do you solve this problem? > >Personally, my program maintains two chess positions: the search engine position >and the user interface position. I have two move generators, one for each >position. I also have two makemove() functions, etc. > >This approach strikes me as bad design, because so much functionality is being >duplicated. > >My idea is to put my search engine in a class. Then I can just make two >instances of that class--one for searching, and the other for the user >interface. > >Then the problem is that the UI doesn't need a lot of the search engine stuff. >It sure doesn't need a PV array, for example. So my latest idea is to make a >"board" class and a derivative "engine" class. The engine class will contain >everything that the UI doesn't need. > >I think this solves the problem neatly, but it's evidently not what most people >do. Is there an easier solution staring me in the face? > >Thanks, >Tom
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.