Re: [boost] [atomic] comments

Subject: Re: [boost] [atomic] comments
From: Helge Bahmann (hcb_at_[hidden])
Date: 2011-11-01 14:41:28

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

that answers the second part but not the first (and is getting off-topic from 
atomic operations)

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

but I *do* care and believe it or not there are people writing applications 
that are memory-bound (doubling the overhead of the reference count in each 
of several millions of objects is *not* funny)

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

I don't quite understand the point -- quite obviously nothing good will happen 
if the applications do not agree on a protocol, and there is nothing that can 
be salvaged

if they do agree on the objects being lock-free, fine

if they do agree on the objects not being lock-free, well then explicit 
locking is faster anyways and you should use your "locked" reference 
implementation of the data structure that you surely wrote to run suitable 
regression tests of your lock-free data structure

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

no problem

Best regards
Helge