I don't quite use "polling" as you define it. IE in Crafty you will never find a thread just sitting and spinning waiting for its siblings to finish whatever they are doing. That "spinner" will quickly be invited into one of its sibling's sub-trees as a result of a split operation.Desperado wrote:Can someone please clarify the term late join.
For me it is simply a thread that joins the party after a group or single
thread is already working on the splitpoint, and it was not considered when
the splitpoint was opened.
Imo there is even no need that the master is the first thread that joins the
party. After the splitpoint has been setup it is flagged as open and does welcome any thread. If the work is done ( no moves left, stopped ) the splitpoint is closed,
which means the worst thing that can happen that the master is running through the SmpSearch() and frees the splitpoint ressource on the splitpoint stack without doing "real" work.
That means further that the splitpoint owner
does not poll for its own splitpoint. The polling is used only if a thread joins
somewhere as slave which includes a waiting master and is solved by a recursive call from the SmpSearch() to the polling function ( commonly named as idleLoop() ) while it is "waiting" ( == polling ).
However, in recursive search, there is exactly one thread that can back up through a split point, that being the thread that originally decided to split at that specific point..
The term "late join" as I use it simply means A splits with B and C at some point, and later D or whatever jumps in at the same split point as if it were in the original split operation. This is not that hard to write. I rewrote the code during the 24.0 development, but I found zero improvement (measurable). Absolutely none. I chose to remove it to keep the code simpler and the bugs more infrequent. I can dig the code up if you'd like to see my take, although it might take a little hunting to find the latest...