Re: [boost] [atomic] comments

Subject: Re: [boost] [atomic] comments
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2011-11-01 14:45:31

On Tuesday, November 01, 2011 19:05:07 Helge Bahmann wrote:
> On Tuesday 01 November 2011 18:44:30 Andrey Semashev wrote:
> > On Tuesday, November 01, 2011 06:57:20 Helge Bahmann wrote:
> > > 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.).

They don't. Like I said, data access model is not always restricted to a queue 
or a stream, and sockets are not well suited for these cases.

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

Gladly, we don't have to discuss my design choices right now. ;)

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

Right, and someone has to port it to these platforms.

Honestly, I think either of us is missing something here. My initial assertion 
was that there is no point in Boost.Atomic on architectures without any 
hardware support for atomic ops. This is irrelevant to the level of support of 
a particular platform by the library. Obviously, porting is required for the 
architectures you mentioned, I'm just saying that you are free to assume that 
you always have some atomic ops on the platform you're trying to support.