Re: [boost] [atomic] comments

Subject: Re: [boost] [atomic] comments
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2011-11-01 13:44:30

On Tuesday, November 01, 2011 06:57:20 Helge Bahmann wrote:
> On Monday 31 October 2011 22:18:16 Andrey Semashev wrote:
> > 
> > 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.

Just to be clear, what penalty are we talking about? Is it +4 bytes to a 
normally 16 bytes atomic<> on x86-64? Because other atomic types are assumed 
to have native atomic ops and don't need that extra storage for the spinlock. 
I'm not aware of the state of things on other architectures, what would the 
penalty be there?

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

I don't see how this is relevant. If you imply that shared memory IPC is 
somehow equivalent to socket IPC, I've got bad news for you.

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

Fair enough.

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

I'm not sure I follow. Are you telling that IA64 and MIPS don't have native 
atomic ops or that they are currently somehow "supported" by Boost.Atomic 
without porting? Even if you don't port Boost.Atomic to these platforms you do 
have to port at least spinlock.