Re: [boost] [atomic] comments

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 
per-instance ...

> > > > 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.

great, thanks!

cheers, tim