Author: James Robertson
Date: 17:55:41 04/07/99
Go up one level in this thread
On April 07, 1999 at 19:35:33, Greg Lazarou wrote:
>Hi James,
>
>Well if you happen to have access to MFC you can use semaphores and to lock and
>unlock a critical resource. Basically the problem is to somehow check and reset
>(or set) a flag in one indivisible operation. Here is some of my code looking
>into a command queue; here we are in the engine looking for UI commands in the
>command queue:
>
>CommandElem * RemoveQueueCommand()
>{
> // the lock for accessing the queue
> CSingleLock CmLock(&CommandSemaphore);
> CommandElem * ptrLocal=NULL;
>
> CmLock.Lock();
> if (CommandQ.IsEmpty() == 0) {
> ptrLocal = (CommandElem *)CommandQ.RemoveHead();
> }
> CmLock.Unlock();
>
> return ptrLocal;
>}
>
>Somewhere in the other thread (in my case the UI or main thread) there is code
>that puts stuff in the queue like this:
>
>void QueueSimple(CommandEnum Comm)
>{
> POSITION pos;
>
> // pointer to a command element
> CommandElem * ptrCommand;
>
> ptrCommand = new CommandElem;
> ptrCommand->TheCommand = Comm;
> commLock.Lock();
> pos = CommandQ.AddTail(ptrCommand);
> commLock.Unlock();
>
>}
>
>The key is that both sets of locks refer to the same global semaphore (must be
>called CommandSemaphore).
>
>Now I'm probably wasting some time here but I try not to check the queue too
>often (I shoot for 5-10 times per second which is adequate to look responsive to
>a human's actions, but does not steal too much performance from the engine's
>loop).
>
>Again, all of this applies and you can try it with very little effort if you
>have the ability to use MFC (I'm sure Borland's OWL has some similar classes to
>the semaphores and locks used above...)
>
>My advice though, is to ignore all of this stuff, forget pondering and stop
>improving JRCP; how will Skaki ever catch up if you keep this nonsense up? :-)
>
>Greg
Yikes! This looks really complicated. You could probably manage all the threads
in a company with something like this! My plan for the threads works like this:
have one 'main' thread that checks for user input, and when appropriate spawns a
search thread. The shared resources will be search stats and stuff that need to
be accessed by the main thread, say, while analyzing a position and periodic
stuff is sent to the interface.
So far it is working out well; I have both my threads communicating (I decided
to use critical sections), and all that is left to be done is smooth out some
synchronizationa and iron out any bugs (none so far!!).
James
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.