what about the case of the processors working _below_ that split point at another one? For example you split at ply=3 using processors 1, 2. Later processor 3 becomes idle and splits with processor 1 or 2 at ply=7. When you get the fail high at ply=3, how do you make your broadcast go beyond 1 and 2, and pick up 3 which is not splitting at that point, but which is working below that point and needs to be stopped as well?hgm wrote:The essence of broadcasting is that you inject a message into a common medium, without knowing who is listening (or in fact, if anyone is listening at all). It is the listener who decides if he is going to pick up the signal.bob wrote:It would seem to me that if you can "selectively broadcast" then you must know who is splitting with whom, else you will unintentionally stop the wrong processors here and there.
In this particular case, the 'medium' would be the particular split node in which the cut-off occurs. THe thread stumbling on the cutoff would set a flag there. Only threads working at the node would poll that flag, the other threads would be unaware of it, and could thus never abort their search in reaction to it. They would be polling their own split nodes.
But even the listeners would not be aware with whom they were splitting. They only have to know _where_ they split.
That was the gist of my question about your "broadcast" because just doing this at a split point is not good enough. You have to consider the splits that might have happened _below_ that split point and take care of those at the same instant. Which means you somehow have to know who is doing what and where it is being done, so when you decide to stop a sub-tree search, you know who is involved in that subtree at any level, and get 'em all.
I suspect you are somehow not considering that problem...