TBB in an already threaded application exception

[scasey67]

I am using TBB in an already threaded application on a Windows (XP, 32 bit) machine. When the parallel_for finishes, I get an exception thrown from spawn_root_and_wait(). Below is my code.

[bash]concurrent_unordered_map Components;

struct UpdateComponents
{
	float Data;
	
	UpdateComponents(float delta_t): Data(delta_t) {};

	void operator() (concurrent_unordered_map::range_type& range) const
	{
		for (concurrent_unordered_map::const_iterator iter = range.begin(); iter != range.end(); ++iter)
		{
			iter->second->update(Data);
		}
	}
};

void ComponentManager::updateComponents(float delta_t)
{
	task_scheduler_init init;
	if (delta_t > 0.0f)
	{
		// Update the components
		parallel_for(Components.range(), UpdateComponents(delta_t));
	}
}


[/bash]

This code sits in a DLL that the already threaded application calls. With a single threaded test application I don't have any issues, just when the DLL is with the target application. I must be missing something somewhere and I have been combing through the documentation. Any help is appreciated, thank you.

(note: the code above is littered with 'lt' and 'gt' and not '<' and '>')

[jimdempseyatthecove]

Try making a test call to your DLL before yourapplication code instantiates its additionalthreads. Have this call perform some innocuous parallel_for or some internal function that established the TBB thread team.

Then see if the next call to your DLL, after establishing your application thread team, succeeds or fails

Jim Dempsey

[scasey67]

Thank you for the response. I cannot do as you have recommended as I do not have access to source for the application (commercial game engine, our license doesn't include source) - just an API.

[scasey67]

Answered my own question.

It wasn't TBB that was the problem, but the metadata that is read in from an XML file forconstructing the ComponentInstance objectsthat was different from the test data.

Strange that the crash happened within a TBB function call whenit was really a null pointer in the simulation. The stack trace showed no indication of this. The way that I found it was to comment out the parallel_for calls and iterated across the containers in the'ye olde fashioned' way and found the culprit.

[jimdempseyatthecove]

Quoting scasey67

Thank you for the response. I cannot do as you have recommended as I do not have access to source for the application (commercial game engine, our license doesn't include source) - just an API.

I saw your other post for the work around.....

However regarding my earlier response

// yourProgram.cpp
...
int main(int argc, int argv[])
{
yourFunctionToInitializeTBBandRunBogus_parallel_for();
...
someCallTo3rdPartyGameEngine());
...
yourTBBcodeContainingCallsToSome3rdPartyGameEngine());
...
}

You do not need the sources to the 3rd party library

[scasey67]

Thanks Jim, I probably wasn't too clear in my post. The work around was for easier debugging (unable to view the data in the concurrent_unordered_map in quick view (VS 2008)). The problem was a malformed object, we fixed the data and have the concurrent methods back in there and everything isworking fine now.

Also, the game engine is where the main() function resides, our DLL is accessed through a game engine DLL: GameEngine.exe -> GameServer.dll -> Our.dll. OurDLLjust sends and receives messages from the server dll and does its own work on our data.

Again, thanks for responding to the thread!