Yep, this makes sense. I was using the book as the reference which did not have the line. In the source code for ::self(), there is an assertion for the innermost_running_task which is initialized to null in the constructor for scheduler but it can get assigned the dummy_task on its execution.
Reference (Open Source).pdf revision 1.13 (may not be latest) says for task::self(): "If the calling thread is a user-created thread that is not running any task, self() returns a reference to an implicit dummy task associated with the thread." So if you want to call task::allocate_additional_child_of() from your own thread, make sure it has an active task_scheduler_init registration, and use task::self().
(Added) It does leave me wondering what this does for ownership, because the owner may go away or become unregistered during the lifetime of the task. What does ownership do besides affecting the outcome of is_stolen_task()?
Intel Software Network Forums Statistics
8491 users have contributed to 31629 threads and 100770 posts to date.
In the past 24 hours, we have 28 new thread(s) 120 new posts(s), and 168 new user(s).
