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:
- controller sends async_genmove
- controller (after some period of time) sends abort.
- engine responds to aysnc_genmove
- 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