On Tuesday, November 01, 2011 11:29:22 Helge Bahmann wrote:
On Tuesday 01 November 2011 10:49:55 Tim Blechmann wrote:
socket communication and shared memory have quite different performance characteristics.
is there some semantic ambiguity to the word "fallback" that escapes me? or do you expect the "fallback" to have the same performance characteristic as the "optimized" implementation, always? then please explain to me how a fallback for atomic variables using locks is going to preserve your expected performance characteristics
Lock-based IPC can be much more efficient than socket-based. That's not mentioning much more sophisticated access models to the shared data that are possible with shared memory. Calling sockets a drop-in replacement for shared memory IPC (whether it uses atomics or locks) is nonsense, IMHO.
right, but the standard implementation for gcc does not use a spinlock per object (see __atomic_flag_for_address) which turns all of this moot - there is NO guarantee for std::atomic to be safe interprocess, period
GCC has the luxury of a shared runtime which can provide process-wide table of spinlocks. Boost.Atomic is header-only, so in multi-module applications this table has to be exported so that all modules use the single table. I mentioned that in the review. Do you have ideas of how to achieve that? Most obvious would be to link to Boost.Atomic dynamically...