effect of "allocate_additional_child_of"?

[softarts]

what's the difference with "allocate_child() "?

[RafSchietekat]

Quoting - softarts

what's the difference with "allocate_child() "?

Have you consulted the documentation at http://www.threadingbuildingblocks.org/ (Tutorial and Reference Manual)? If something is not quite clear there, and you explain what that is, perhaps the documentation can be improved.

The main point is that allocate_additional_child_of() is slightly slower than using set_ref_count() and allocate_child() (although I don't know by how much), but set_ref_count() must not be used after you spawn the first child.

[softarts]

Quoting - Raf Schietekat

Have you consulted the documentation at http://www.threadingbuildingblocks.org/ (Tutorial and Reference Manual)? If something is not quite clear there, and you explain what that is, perhaps the documentation can be improved.

The main point is that allocate_additional_child_of() is slightly slower than using set_refcount() and allocate_child() (although I don't know by how much), but set_refcount() must not be used after you spawn the first child.

the nutshell book "intel threading building blocks" mentioned that

"In general, the allocation methods must be called before any of the tasks allocated are
spawned. The exception to this rule is allocate_additional_child_of(t), which can be
called even if task t is already running. The proxy types are defined by the implementa-
tion. Because these methods are used idiomatically, the headings in the subsection show
the idiom, not the declaration. The argument this is typically implicit, but it is shown
explicitly in the headings to distinguish instance methods from static methods."

it doesn't talk about the implementation and idea behind the function,and I find that the task allocated by this func can be stolen by other thread(that means task is executed in parallelism?),
but allocate_child can not do that?

i.e. pipeline.cpp use this to spawn a child task.
so that
TRACE show "7FF97F00.internal_spawn enter" and the other thread(scheduler) can execute the task concurrently.

that 's why it confuse me

[RafSchietekat]

I wonder, did you consider yet that if you call set_ref_count(4), expecting to spawn 4 child tasks, and spawn the first child task, that even right after spawning you cannot possibly know whether ref_count is still 4 or has already dropped to 3, because the spawned task may or may not have finished and concurrently decremented the ref_count? So you never know what value to provide if you change your mind and want to spawn an additional task. That's what allocate_additional_child_of() is for: if you know that the parent has not finished waiting for its children, you can use this function, which basically works as {concurrently_increment_ref_count(); allocate_child();} (where the first function is only conceptual). which basically works as { allocate_child(); concurrently_increment_ref_count(); } (where thesecond function is only conceptual).

"it doesn't talk about the implementation"
Both allocate_child() and allocate_additional_child_of() have transition diagrams to indicate what you need to know, but TBB is open source, so feel free to have a look for yourself at things that a user does not need to know.

"and idea behind the function,"
It does what its name implies. I would be surprised if it makes any noticeable performance difference, though: I suspect that this is somewhat of an accident of history, but to me that's not worth worrying about. At some point I have proposed something like a concurrent add_ref_count() operation (if I remember correctly), but that was because of a specific reason related to recycling tasks.

"and I find that the task allocated by this func can be stolen by other thread(that means task is executed in parallelism?),
but allocate_child can not do that?"
Anyspawned task can be stolen before it starts executing, however it was allocated.

"i.e. pipeline.cpp use this to spawn a child task.
so that
TRACE show "7FF97F00.internal_spawn enter" and the other thread(scheduler) can execute the task concurrently.

that 's why it confuse me"
I'm also confused, so if you still need to know, you'll have to explain what you mean. :-)

(Corrections) See text.

[softarts]

Quoting - Raf Schietekat

I wonder, did you consider yet that if you call set_ref_count(4), expecting to spawn 4 child tasks, and spawn the first child task, that even right after spawning you cannot possibly know whether ref_count is still 4 or has already dropped to 3, because the spawned task may or may not have finished and concurrently decremented the ref_count? So you never know what value to provide if you change your mind and want to spawn an additional task. That's what allocate_additional_child_of() is for: if you know that the parent has not finished waiting for its children, you can use this function, which basically works as {concurrently_increment_ref_count(); allocate_child();} (where the first function is only conceptual). which basically works as { allocate_child(); concurrently_increment_ref_count(); } (where thesecond function is only conceptual).

"it doesn't talk about the implementation"
Both allocate_child() and allocate_additional_child_of() have transition diagrams to indicate what you need to know, but TBB is open source, so feel free to have a look for yourself at things that a user does not need to know.

"and idea behind the function,"
It does what its name implies. I would be surprised if it makes any noticeable performance difference, though: I suspect that this is somewhat of an accident of history, but to me that's not worth worrying about. At some point I have proposed something like a concurrent add_ref_count() operation (if I remember correctly), but that was because of a specific reason related to recycling tasks.

"and I find that the task allocated by this func can be stolen by other thread(that means task is executed in parallelism?),
but allocate_child can not do that?"
Anyspawned task can be stolen before it starts executing, however it was allocated.

"i.e. pipeline.cpp use this to spawn a child task.
so that
TRACE show "7FF97F00.internal_spawn enter" and the other thread(scheduler) can execute the task concurrently.

that 's why it confuse me"
I'm also confused, so if you still need to know, you'll have to explain what you mean. :-)

(Corrections) See text.

hi Raf,thanks your post
I have thought "allocate_additional_child_of" result that the task is unable to be executed concurrently,
but seems it is caused by spawn_and_wait()
thank you again