Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Hey, I do that!

Author: Miguel A. Ballicora

Date: 14:31:45 03/08/02

Go up one level in this thread


On March 08, 2002 at 15:58:50, Sune Fischer wrote:

>On March 08, 2002 at 15:15:34, Miguel A. Ballicora wrote:
>
>I have a related question about this polling thing.
>
>How does one exit the searching thread cleanly when the polling thread finds a
>command, like a move from the opponent that requires the search to stop?
>I don't know a whole lot about threads, but is it possible to kill the thread
>cleanly, so will it clean up all the garbage of memory allocations done in the
>search?

The input thread can set a global variable that the search thread checks
once in a while. For instance, the searching thread has to check is time
is up, so at the same time can check if the global variable was set. Then, the
searching thread will terminate gracefully as if the time was up. Meantime,
the input thread has to wait for the search thread to terminate
(WaitForSingleObject). This global variable has to be volatile.

That's how I do it, I have an input thread that launches the search thread.
Then, it controls it with global variables. I need very few.
In this way, I use only two multithreading functions: _beginthreadex and
WaitForSingleObject (or pthread_create and pthread_join in POSIX if I remember
correctly the names). No mutex, no critical sections or anything like that.
It took me very little time to port it to POSIX from NT threads, just to find
the right equivalent functions, make a wrapper and watch the syntaxis.

BTW, I know very little about threads either :-)

Regards,
Miguel


>Since it is a recursive function one obviously cannot just call return to get
>out.
>Is there a way around this if one does not use threads (yet)?
>
>-S.
>
>
>>>But in this case, the thread fulfills it own condition, i.e. the polling thread
>>>calls fgets() and doesn't do anything until it gets it.  The only interaction
>>>with the main thread is when the main thread checks the inputWaiting flag.  So
>>>it doesn't seem like mutexes or semaphores would apply, according to your brief
>>>description. (Then again, what do I know...)
>>>
>>>btw, I am compiling with the Borland C++ free compiler right now, if that
>>>affects anyone's response.
>>
>>I do not like this design, but it is a matter of taste. Hhowever, if you are
>>looking for solution try to introduce in the loop sleep(x) when x is IIRC
>>miliseconds where the thread will sit doing nothing. So, if you do
>>sleep(100) the thread will poll every 0.1 seconds and will consume almost
>>no cpu.
>>
>>Regards,
>>Miguel
>>
>>will
>>you can int



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.