Subject: Re: [boost] [atomic] comments
From: Tim Blechmann (tim_at_[hidden])
Date: 2011-10-23 05:28:33
> > > well if the atomics are truely atomic, then BOOST_ATOMIC_*_LOCK_FREE
> > > == 2 and I find a platform where you cannot use them safely between
> > > processes difficult to imagine (not that something like that could
> > > not exist)>
> > one would have to do the dispatching logic in the preprocessor, so one
> > cannot dispatch depending on the typedef operator.
> it's certainly possible to build a helper template to map types to these
> macro values (map to the value of BOOST_ATOMIC_INT_LOCK_FREE for all types
> T with sizeof(T) == sizeof(int) for example)
yes ... iac, i would have preferred the semantics of dispatching on a per-
class (or per-size basis) myself. but unfortunately atomic::is_lock_free is
> > > > in the average, but not in the worst case. for real-time systems
> > > > it is not acceptable that the os preempts a real-time thread
> > > > while it is holding a spinlock.
> > >
> > > prio-inheriting mutexes are usually much faster than cmpxchg16b --
> > > use
> > > these for hard real-time (changing the fallback path to use PI
> > > mutexes as well might even be something to consider)
> > do you have some numbers which latencies can be achieved with PI
> > mutexes?
> no I don't, but the literature measuring wakeup latencies in operating
> systems is plentiful
last year i performed some benchmarks for the worst-case wakeup latencies on
linux. on highly optimized systems with PREEMPT_RT you can get a worst-case of
about 20us, however with a vanilla `low-latency' kernel, you have a worst case
of about 300us (quite significant for me, targetting deadlines of about 1ms).
> I only have throughput numbers, and these peg a double-word-CAS operation as
> slightly less than twice as expensive as single-word-CAS -- considering
> that most protocols need one pair of (either single- or double-word) CAS,
> and considering that PI mutex lock/unlock can essentially be just a CAS on
> the lock variable (to store/clear the owner id) in the fast path, PI
> mutexes usually end up faster
well, according to my experience on a stock operating system the worst-case
performance is about a 100 times slower than the average case ...
> Nevertheless I will add cmpxchg16b for experimentation.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk