[computer-go] GTPv3

[Don Dailey]

On Thu, 2007-03-08 at 12:27 -0500, Weston Markham wrote:
> >
> > 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.

I think I am confused.

So what you might get is this:

  1. controller sends async_genmove
  2. controller (after some period of time) sends abort.
  3. engine responds to aysnc_genmove 
  4. engine responds to the abort search

In my example, I'm assuming the engine send it's response to
asyn_genmove
at the same instant the controller wanted to abort the search,  so the
engine didn't see the abort comming before it was too late.  

Isn't this a race condition?   I believe this should cause no problems
because the controller can simply ignore the non-relevant response to
genmove (it knows it send abort.)   But I don't think that is what you
are talking about.

- Don