Lots of reasons. I may not have access to all platforms, to begin with. I may not have enough knowledge about hardware capabilities of all of the platforms. Manual porting to multitude platforms may be expensive.> > This is ridiculous. May I invite you to have a look at socket communication via boost.asio?
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
imo, `fallback' would mean that i can still compile the program, without the need to provide a different implementation for the case that atomics are not lockfree/interprocess safe.
e.g. i would not trust on accessing sockets from a real-time thread.
what makes you believe that message channels in real-time systems were designed so dumb as to make them unusable for real-time purposes?
life would be so much easier for me, if the users of my software would not run on off-the-shelf operating systems ;)
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
well, i'd say this is a problem of gcc's implementation of std::atomic. this doesn't justify that boost.atomic does not follow the suggestion of the standard. cheers, tim