[computer-go] GTPv3

[Paul Pogonyshev]

Don Dailey wrote:
> 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.

[Please CC to GTP list]

Engine should send response in this way:

  acquire response lock
  check if asynchronous command hasn't been aborted/completed
  if not, send response
  release lock

In other words, there is potential for race condition, as with anything
asynchronous.  But properly implemented engine doesn't have a race
condition situation.  Yes, it is more complicated.  That's why I'm
against making asynchronous stuff required, only optional.

Paul