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 _______________________________________________ computer-go mailing list [email protected] http://www.computer-go.org/mailman/listinfo/computer-go/
