Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Hey, I do that!

Author: Miguel A. Ballicora

Date: 15:41:38 03/08/02

Go up one level in this thread


On March 08, 2002 at 17:50:44, Sune Fischer wrote:

>On March 08, 2002 at 17:31:45, Miguel A. Ballicora wrote:
>
>>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.
>>
>
>Yes I understand about the global falg and all, but how do you terminate
>gracefully? Is there a killthread() that does this?

When you call _beginthreadex (or pthread_create) you provide the address of
a function. The thread starts and call this function, which could be something
like think() in a search thread. When think() returns, that terminates
the thread automatically. You can wait this termination with
WaitForSingleObject. Basically, the thread terminate itself just returning.

That is why I said that you provide the (global) message to the thread and
then you do not have to kill it.  You just wait for its suicide :-)

Of course there are ways to kill a thread like you say, but it is not necessary
and in a chess program is not "graceful" either.

Regards,
Miguel






>
>>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.