Reputation: 11431
I am using tbb programming in C++. I am not supposed to use message queue, FIFO, PIPES etc as it is platform specific. I am supposed to use tbb specific API's.
Thread1: // Pseuodo code exits as below
// I will take mutex
m_bIsNewSubsArrived = true;
StartSubscriptionTimer();
m_bIsFristSubsArrived = true;
// Spawn a thread here.
if(m_tbbTimerThread == NULL)
{
m_bIsTimerMutexTaken = true;
m_timerMutex.lock();
m_tbbTimerThread = new tbb::tbb_thread(&WaitForTimerMutex, this);
if (m_tbbTimerThread->native_handle() == 0)
{
// report error and return.
return;
}
}
// Thread 1 exited.
In another thead I am releasing mutex which is taken above.
Thread 2.
m_timerMutex.unlock();
m_bIsTimerMutexTaken = false;
Thread 3:
// I am waiting for mutex
m_timerMutex.lock();
In above code problem I think is thread 1 which locked m_timerMutex is not relased so I think thread2 not able to unlock. And thread 3 is blocked for ever.
I think I can use sempahore, but what are API's for sempahore in TBB.
What is the best technique I can do this with out sleeping and using tbb specific API's.
Thanks for your time and help.
Upvotes: 0
Views: 1150
Reputation: 4049
There is currently no support for semaphores in TBB. The reason is that TBB is intended to raise the level of abstraction above raw threads to the level of tasks, and semaphores are considered a low-level "goto" of threaded programming. Note that C++11 does not have semaphores either.
Using tasks instead of threads often allows synchronization to become implicit, and often permits automatic load balancing via the work-stealing scheduler in TBB.
If your problem is not amenable to a task-based solution, consider using condition variables, which are part of C++11. Recent versions of TBB ship with a partial implementation of C++11 condition variables.
Upvotes: 2
Reputation: 6573
I've never used tbb, but typically you can only release a mutex in the thread currently holding it (which is kind of the purpose of a mutex). From the code shown here, Thread1
is still holding the mutex, Thread2
can't release it because it doesn't hold it (don't know what the behavior is there in the Intel implementation, have to look this up) and Thread3
is waiting forever because Thread1
is still holding the mutex.
(But I'm just guessing, because you didn't tell us what's actually happening with the code you've got so far, or what exactly you are trying to do)
Upvotes: 1