Intel® oneAPI Threading Building Blocks
Ask questions and share information about adding parallelism to your applications when using this threading library.
2464 Discussions

tbb::task::self().is_owned_by_current_thread() fails?

mwhenson
Beginner
565 Views
Hey all - I must be misunderstanding something somewhere. I occasionally get an error on the following:
[cpp][/cpp]

[cpp]		if(!is_owned_by_current_thread())
{
assert(tbb::task::self().is_owned_by_current_thread());
tbb::task::self().destroy(*this);
}
else
destroy(*this);

sometimes both this->is_owned_by_current_thread() and tbb::task::self.is_owned_by_current_thread both fail. How could this be happening and what can I do about it? I need to be able to destroy a task here. Thanks!

Mike[/cpp]
0 Kudos
9 Replies
Alexey-Kukanov
Employee
565 Views

Inmy understanding, task::self() should never fail this assertion if the current thread has an active TBB scheduler.

Do you see the issue with pre-built TBB binaries? What package? If using debug TBB library, are there any TBB assertions failing? And would you be able to provide a reproducer test case that would help in debugging?

0 Kudos
mwhenson
Beginner
565 Views
Quoting - Alexey Kukanov

Inmy understanding, task::self() should never fail this assertion if the current thread has an active TBB scheduler.

Do you see the issue with pre-built TBB binaries? What package? If using debug TBB library, are there any TBB assertions failing? And would you be able to provide a reproducer test case that would help in debugging?

I'm using TBB Debug library 2.1. I get an assertion failure in TBB. "Assertion t.is_owned_by_current_thread() failed on line 1120 of file ../../src/tbb/task.cpp Detailed Description: task owned by different thread". It happens when calling tbb::task::self().destroy(*this);

This assertion to occurs after an exception has been thrown, and semi-randomly (only about 2/3rd of the time does the exception actually occur) I don't have a simplified framework to reproduce the error unfortunately...

0 Kudos
mwhenson
Beginner
565 Views

Actually, it seems like tbb::task::self() is not accessable in a task's destructor fairly often. Why is this the case?

As given in this example that Arch posted here that I've modified a bit, the program crashes after a couple calls to tbb::task::self().

Thanks for any help.

Mike

0 Kudos
ARCH_R_Intel
Employee
565 Views
Quoting - mwhenso

Actually, it seems like tbb::task::self() is not accessable in a task's destructor fairly often. Why is this the case?


self() was originally intended to be valid only when task::execute is running. It returns the innermost task whose execute() method the current thread is running. Once that task finishes its execute method (and before its destruction), self() becomes the next task up the chain. When a thread is not executing any task, self() returns a pointer to a dummy task that behaves much "as if" the thread is running inside its execute method.

By the time a task's destructor runs, its execute method is not running.

I'm still puzzled over how self().is_owned_by_current_thread() could ever return false. Any self-contained example appreciated.

0 Kudos
ARCH_R_Intel
Employee
565 Views
Quoting - ARCH ROBISON (Intel)
self() was originally intended to be valid only when task::execute is running. It returns the innermost task whose execute() method the current thread is running. Once that task finishes its execute method (and before its destruction), self() becomes the next task up the chain. When a thread is not executing any task, self() returns a pointer to a dummy task that behaves much "as if" the thread is running inside its execute method.

By the time a task's destructor runs, its execute method is not running.

I'm still puzzled over how self().is_owned_by_current_thread() could ever return false. Any self-contained example appreciated.

I looked into the scheduler, and actually we do not reset the "innermost task" variable until after the destructor runs. So self() should point to the task whose destructor is running, if the destructor is being automatically invoked by TBB after it runs the task.

0 Kudos
Alexey-Kukanov
Employee
565 Views
I think I might know what the trouble is. I will create a change request fora fix.
0 Kudos
mwhenson
Beginner
565 Views
Quoting - Alexey Kukanov
I think I might know what the trouble is. I will create a change request fora fix.

What do you think the problem might be? I've been working on a self-contained testbed, do you think that would still be useful? Also, not sure if it's relevant, but I'm using VC9. Thanks!

Mike

0 Kudos
Alexey-Kukanov
Employee
565 Views
Actually, same as Arch wrote above - I did not see his answer when wrote mine.
The self-contained test would definitely be useful! We will also try to make a reproducer, but your help is much appreciated, and you are probably ina better starting position to create it.
0 Kudos
mwhenson
Beginner
565 Views
Quoting - Alexey Kukanov
Actually, same as Arch wrote above - I did not see his answer when wrote mine.
The self-contained test would definitely be useful! We will also try to make a reproducer, but your help is much appreciated, and you are probably ina better starting position to create it.

I couldn't figure out how to send an email using these new forums. I emailed Arch the code, as I had had a previous correspondence with him. Thanks any help you can provide,

Mike

0 Kudos
Reply