- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Timeouts are deliberately missing by design, but we should consider adding them. You posted at a good time because we're trying to draw up feature requests for TBB >2.1.
The initial design of TBB targeted a paradigm of task-based programming for parallel speedup. It is what I think of as "classical" parallel algorithms like parallel_for, parallel_reduce, etc.The containers and mutexes were designed with that in mind; i.e., to avoid race conditions.Blocking was expected to be short, otherwise the program would not scale. Therefore timeouts were not a priority.
However, it's clear that TBB is used in contexts beyond classical parallel algorithms, and in those contexts timeoutscan be appropriate. Indeed, there is one timeout already in TBB: function tbb::tbb_this_thread::thread_sleep sleeps for a specific time duration.
In the current TBB, the best way to periodically attend to an event would be to create a separate tbb::tbb_thread and have it do the periodic work, and sleep for each period.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
After some good discussion about timed_mutex in TBB, we decided to post a blog article (http://softwareblogs.intel.com/2008/09/17/pondering-timed-mutex/) to see how people, in particular, C++ developers and TBB users, think of the idea. Please let us know what you think.
thanks a lot
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
MADwkim3:
After some good discussion about timed_mutex in TBB, we decided to post a blog article (http://softwareblogs.intel.com/2008/09/17/pondering-timed-mutex/) to see how people, in particular, C++ developers and TBB users, think of the idea. Please let us know what you think.
Personally I can't remember when I was using timed lock for something else than some temporal hack.
"Can we still call it spin_mutex after we add wait/time-out to it?"
I think, yes. The main feature and advantage of spin-mutex is lightweight release and absence of heavyweight signaling. If you will add timed wait, those properties will still hold.
"Secondly, platforms differ in the degree to which they support timed mutexes"
I think that Win32's CRITICAL_SECTION must be considered as NON supporting timed waits. And it's a significant precedent wrt utility of timed mutexes.
"Andrey Marochko suggested self-restarting servers as a use case -- if a server cannot acquire a mutex for a pre-set period of time, it may assume that an unrecoverable error has occurred and restart itself."
My personal opinion is that timed mutexes have nothing to do with self-reviving servers. Server can deadlock/livelock in any point in the code, not only on mutex acquisition. So self-reviving servers usually implemented with watchdog timers and keepalives.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As for the following implementation:
template
bool try_acquire_with_timeout( Mutex& mutex, typename Mutex::scoped_lock& lock, const size_t interval_in_milli /* in milliseconds */)
{
internal::AtomicBackoff bo;
TBB_ASSERT( interval>0, NULL );
size_t interval_in_micro = interval_in_milli * 1000; /* convert it to usec */
tick_count::interval_t i_100( 0.0001 /* seconds */); // 100 micro seconds == 0.1 milli seconds = 0.1*10.0E-3
do {
if( lock.try_acquire( mutex ) )
return true;
if( !bo.bounded_pause() ) {
this_tbb_thread::sleep(i_100); // sleep for 100 micro seconds
interval_in_micro -= 100;
bo.reset();
}
} while ( interval_in_micro>0 ) ;
return false;
}
The moment I'm concerned with it "this_tbb_thread::sleep(i_100)".
AFAIK in some circumstances Windows will put thread to sleep for scheduling granularity, i.e. 15 ms. Such implementation can be very non-reactive. I think it's better to call few times 'SwitchToThread()' and then 'Sleep(0)'.
Btw, this way user can implement timed lock manually, with any backoff strategy he wants.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page