Author: James Swafford
Date: 08:23:02 02/17/01
Go up one level in this thread
On February 17, 2001 at 07:47:12, David Rasmussen wrote: >I am about to add pondering and other things to my program, and I basically need >unblocking I/O. As I can see from everybody elses sourcecode and by asking >experts, there is no way to do this in a portable way in C++. That is in itself >annoying, as it would be no problem to have a stream method that tried to fetch >some items from the underlying buffer or I/O device, and if there wasn't any >items immediately, it returned. > >That being said, I would like to do the next best thing. I would like to have >the simplest and "most" portable way of doing this. I'm beginning to think that >the most portable way (and also the simplest way) is to use pthreads from the >start (which would come in handy anyway, if I decided to make a multiprocessor >version of my program), and have a seperate threat listening on cin for new >input. In this way I wouldn't have to deal with the console vs. pipe issue under >certain OS'es, i.e. Windows. I think pthreads exists on most platforms that I >would care about. Or at least some very equivalent thread library, that would >make it easy to have #defines or inline functions "translating" from pthread >calls to these calls. > >Anyway, I don't have any clear question other than: What is your take on this? >What would you do? How has this been done? etc. I have played with two methods. The first method was pretty much what you're talking about: I spawned off a thread that just listened to STDIN, and when something "came in", responded. Certain commands required the search to stop, some didn't. For example, "?" (move now) would trigger a global flag that would trigger the search to abort and the engine to play the best move it has. Another situation occured when the engine was searching (during a ponder), and a move came in. The initial pos was saved at the root. The move was compared to the move the engine was thinking about. If identical, it either kept on thinking or made a move, depending on time allocation. The second method, as you mentioned, is polling during the search like Crafty. I personally don't like that method as much as using a thread based approach. The real trick to using threads was the locking mechanisms. It takes some real thought and a few cokes to bullet proof your program if you're gonna use threads. Even when I thought mine was solid, it would eventually die because of an unprotected variable. My stuff was in MSVC, using _beginthread( ) and a bunch of CSingleLock's in the MFC lib. I started to port that program (Tristram) to gcc using pthreads, but I moved on to other projects before I finished. Now I do most of my development on a Linux machine, so I'll probably revisit that one of these days with my current project. Anyway, to cut to the point: if you're worried about portability, and you want to be able to compile on Win32, using threads is probably less portable. A possible exception would be compiling with Cygnus's gcc port, but I don't think they have implemented pthreads. In spite of all that, I would go with the thread based approach. But stock up on aspirin and some kind of caffeine product. :-) -- James > >I'm aware that Crafty implements a way to do this, that others have borrowed. >But to be honest, I don't like Crafty's solution very much. I would like >something simpler, more portable etc. perhaps utilizing something that C++ has >that C does not have.
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.