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