On Tuesday 01 November 2011 19:08:20 Andrey Semashev wrote:
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.
Well then create a shared memory region and use explicit locking. This is even more efficient than the many implicit locks in miniscule atomic objects. See, by *not* exporting the spinlock of the fallback path of atomic<> objects I just made your IPC even more efficient.
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...
the same way shared_ptr treats its spinlock pool (template specialization, and I guess this leads to a symbol with virtual linkage, the instances all of which are collapsed into a single instance by the run-time linker) Best regards Helge