On 3/7/07, Paul Pogonyshev <[EMAIL PROTECTED]> wrote:
Don Dailey wrote:
> On Wed, 2007-03-07 at 22:53 +0100, Gunnar Farneback wrote:
> > * To abort the asynchronous genmove, the controller should send the
> > (synchronous) command abort_async_genmove. If the engine has not
> > returned the asynchronous genmove response before responding to the
> > abort command, it is no longer allowed to return a move. I'm open
> > for
> > discussion on the exact name and whether it should return an error
> > if
> > the move had already been sent (I don't think it should).
>
> But what about race conditions here? The engine may be responding to
> the async_genmove command an instant before it realizes an abort
> command
> just arrived. In this case it would be violating your rule but it
> wouldn't be anyone's fault.
There is no race condition because commands _are_ read synchronously.
But responses _may be_ sent asynchronously.
Paul
I'm not sure that I understand Paul's explanation, so I'll try out my
own: Any race condition that occurs here is entirely the fault of the
engine. The engine is already responsible for serializing all of the
responses that it makes. Any failure to do so would allow interleaved
responses, which could not possibly be understood by the controller.
So, at the time that the async_genmove is permitted to write its
asynchronous response, (it may have to acquire a lock in order for
this to be the case) it is unambiguous whether or not the response to
abort_async_genmove has been sent.
Weston
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
