#ifdef SETUP_TIMER_WAITING bool TimerWait(EventCallBack WaitCB, int Id = 0, bool OptCondition = true); bool DoneWait(); void SetTimer(); bool DoneWaiting; bool StartWait; int Id; HANDLE hTimer; HANDLE hTimerQueue; #endif
private: #ifdef _WIN32 HANDLE m_hEvent; /* If we have waited more than five seconds we can be pretty sure that the thread is deadlocked. So then we can just as well continue and hope for the best. I could try several times that this works after a five second timeout (with works meaning that the game stopped and I could start another game without any noticable problems). But several times it failed to, and ended with a crash. But it's better than an infinite deadlock. */ static const int THREAD_WAIT_TIMEOUT = 5000; // INFINITE or 5000 for example #else bool is_set_; pthread_cond_t event_; pthread_mutex_t mutex_; #endif };
TBB's strength does not lay in threads the way you are using them, although its called Threading Building Blocks :)
In TBB you'd use TBB::thread objects to do what you are doing, but TBB is more about abstracting threads away and programming in tasks Tasking Building Blocks, might be a better name ;)
The advantage of the TBB approach is the system can easily scale to more processors, or more work load.
If all you need is to simplify your code I'd use boost::thread, it abstracts away implementation details, and most projects already use boost for that matter. But TBB is a great tool if you can restructure your program, but that depends on your needs and timelines.