Community
cancel
Showing results for 
Search instead for 
Did you mean: 
mwhenson
Beginner
58 Views

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

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_K_Intel3
Employee
58 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?

mwhenson
Beginner
58 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...

mwhenson
Beginner
58 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

ARCH_R_Intel
Employee
58 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.

ARCH_R_Intel
Employee
58 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.

Alexey_K_Intel3
Employee
58 Views

I think I might know what the trouble is. I will create a change request fora fix.
mwhenson
Beginner
58 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

Alexey_K_Intel3
Employee
58 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.
mwhenson
Beginner
58 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

Reply