Re: [boost] [atomic] comments

Subject: Re: [boost] [atomic] comments
From: Tim Blechmann (tim_at_[hidden])
Date: 2011-11-01 13:54:22

> > 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