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.
implementing the fallback for something as simple as a "queue" via some socket-based IPC is an entry-level question in a programmer job interview, so the effort required is rather trivial
... it may be trivial, but it still takes time ... apart from that, there are more complex communication mechanisms than a `queue'
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 ;)
and what makes you believe that the performance characteristics of sockets in off-the-shelf operating systems is unsuitable for real-time, while the process scheduling characteristics of process scheduling in off-the-shelf operating systems is suitable for real-time?
i cannot comment on windows, but both osx and linux provide ways to schedule a thread at a priority that it won't be preempted by any other thread, so the process scheduler won't interfere.
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.
the standard says "should" not "must" -- the gcc guys have not made this decision without good reasons, and I agree with these reasons
note that there is also trouble lurking with run-time selection of whether something like atomic<uint64_t> is atomic via cmpxchg8b: do you really want to make this at minimum 12 bytes in size (though effectively occupying 16 due to alignment) just to save the room for the rarely-if-ever used per-object spinlock? same with atomic<128> and cmpxchg16b ?
i don't really care about the size of an atomic<>. one other point for runtime selection is compatibility. e.g. you may have two binaries, one is compiled with support for double-width CAS, the other one without. with compile-time dispatching the behavior would be undefined, with run-time selection, it would be handled gracefully ...
2. What is wrong with implementing boost::interprocess::atomic<T> that specializes to boost::atomic<T> when possible and uses an interprocess lock otherwise?
will you provide an implementation? people were asking for boost::interprocess support during the boost.lockfree review. the only missing feature is the atomic<> implementation. cheers, tim