Re: [boost] [atomic] comments

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

On Monday 31 October 2011 22:18:16 Andrey Semashev wrote:
> On Monday, October 31, 2011 21:33:19 Helge Bahmann wrote:
> > > I have to disagree. Atomics may be used to communicate processes just
> > > as well as threads, if not better.
> >
> > the question is not whether they *can* be used, but which case is more
> > common -- and considering the enormous amount of simple atomic
> > counters, "init-once" atomic pointers etc. found in typical applications
> > make me doubtful that inter-process coordination accounts for more than
> > 1% of use cases
>
> But that doesn't make the inter-process use case a second class citizen,
> does it? The implementation should support it just as well as intra-process
> cases.

If adding support for one use case penalizes another one, it is a balancing 
question and you have to answer "which one is more frequent", it's as simple 
as that.

> > > I want to be able to write atomic< index_t > so that it compiles and
> > > works on any platform, even without 64-bit CAS support in hardware. It
> > > may work slower, yes, but it will.
> >
> > what's wrong with just implementing a platform-specific "ipc queue"?
>
> 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?

So this essentially boils down to that you consider it okay to penalize the 
common use case for atomic operations just to spare you the trivial 
implementation expense of using existing IPC as fallback?

Besides there is still the option of implementing something 
like "interprocess.atomic" that does what you want, without penalizing the 
process-local case.

[...]
> > > I think, having a mutex per atomic instance is an overkill. However, a
> > > spinlock per instance might just be the silver bullet. The size
> > > overhead should be quite modest (1 to 4 bytes, I presume) and the
> > > performance would still be decent. After all, atomic<> is intended to
> > > be used with relatively small types with simple operations, such as
> > > copying and arithmetics. In other cases it is natural to use explicit
> > > mutexes, and we could emphasise it in the docs.
> >
> > might be possible, the problem is that this assumes that there is
> > atomic<something> available -- as soon as you hit a platform where
> > everything hits the fallback, you just have to use a mutex and the cost
> > becomes unbearable
>
> True. But are there realistic platforms without any support of atomic ops
> whatsoever today? If there are, I'm not sure the library should support
> these platforms in the first place.

if it is not ported to the platform then nothing is avaialble. I have only 
recently finished sparcv9 implementation, itanium and mips still missing, so 
they would suffer immediately.

Best regards
Helge