It depends on how other things are done. I guess. I have two threads, one that interacts with "input from/output to" the interface and another that "thinks" (but also outputs search results like bestmove).
The first thread holds a key (mutex) for the "bestmove" output of the second thread. It releases the key only after receiving "stop" or "ponderhit". That way, the engine never wastes cycles because it gets blocked by a mutex.
Miguel
Desperado wrote:[d]5k2/1p3pb1/p2p4/5p1P/b1P5/P5r1/3q4/5R1K b - - 0 36
well, i was just in mood to watch my engine playing some bullet games.
When the above position occured, Nemo(black pieces) already looped over all iterations (in ponder-mode)
It is forced to send a move when all iterations are done, which was
of course ignored by the gui, and so Nemo(with 30s, very painful) lost on time because
ponderhit jumps into no-where so to say. (dead lock...).
Or in other words, ponder-search was finished before Sjeng finished the
search process for Kg1-Kh1, so before the move was played.
i am not sure how to handle that case at first glance, when pondering.
Of course i can reserve the best move and switch to some kind of idle-loop, until the ponderhit command is received or whatever.
now a simple question, what are your engines doing in that case ?
in my case it was finally a really trivial fix.
Similar to Marcos proposal i catch the case directly in my
uciSendBestMove() procedure. It checks now if it is in ponderMode
or already received stop/ponderhit command. If not it is simply waiting
for these commands or will quit on a quit request.Otherwise the move
will be sent.
The wating conditions are easy to extend, but currently only in pondering
mode the communication would break if the move is sent directly.
(For infiniteMode this is ignored although the uci protocol requires waiting for a stop command.I just sendBestMove after mayPly is reached.
Any comments on this ?!)
in my case it was finally a really trivial fix.
Similar to Marcos proposal i catch the case directly in my
uciSendBestMove() procedure. It checks now if it is in ponderMode
or already received stop/ponderhit command. If not it is simply waiting
for these commands or will quit on a quit request.Otherwise the move
will be sent.
The wating conditions are easy to extend, but currently only in pondering
mode the communication would break if the move is sent directly.
(For infiniteMode this is ignored although the uci protocol requires waiting for a stop command.I just sendBestMove after mayPly is reached.
Any comments on this ?!)
Michael
Hi Michael,
from the viewpoint of clean programming this is a "hack" ... I would never recommend to wait for input in a function called "...send...", instead I would separate these tasks, supposedly at a higher level where you call your "uciSendBestMove" function. At least that function name now no longer appears to be well-chosen, but when attempting to rename it you will quickly reach the point where names are getting too complex, which usually indicates that the function does too much. Better simplify the algorithm around it.
Marco's proposal was in fact different, and cleaner w.r.t. my comment above, since it did not include sending bestmove in the same function that waits for certain input.
only the _delay()_ function is added (ok, i named it ponderWait() )
For now i dont see a hack in it, because sending bestmove requires
conditions, so i test them within the procedure instead each time outside.
(i only wrote that i put the code directly into the fuction, because i can manual inline it at this point.
And it isnt called from another point at the moment.
If necessary the delay code can be put elsewhere).
hgm wrote:The protocol as I understand it requires you to wait for stop or ponderhitbefore you can send bestmove. An engine should never spontaneously send a move while pondering.
No one 'forces' you to send a move when you finished all iterations during ponder. In fact, no one forces you to ponder. It would even be illegal to ponder unless the engine was asked to do so. So you must know how to handle the case where the engne is idle, waiting for input.
While Crafty is not UCI, the same problem occurs in the WB protocol. I can only ponder to 60 plies (max depth). What do I do when I run out of iterations and my opponent has not moved? I sit and wait for his move. If it matches, I then send the result of the ponder search... That should work perfectly in UCI as well.
)