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