Re: [boost] [atomic] comments

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

On Tuesday 01 November 2011 18:44:30 Andrey Semashev wrote:
> 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?

see other post for more examples (8 bytes for 4 byte atomic on sparc, >16 
bytes overhead on PA-RISC)

and note that due to alignment requirements that would effectively make a 16 
byte atomic on x86-64 occupy 32 bytes (just put two atomic<tagged_ptr> 
instances side by side)

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

Upper layers are not supposed to care about the IPC mechanism but its 
semantics (buffer size, datagram size, datagram loss/ordering, capacity, 
over-/underflow behavior blocking, etc.).

If in your design upper layers need to be intrinsically aware of the innards 
of your IPC mechanism, then I have bad news about your architecture.

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

falling back to spinlock from shared_ptr

Best regards
Helge