Re: [boost] [atomic] comments

Subject: Re: [boost] [atomic] comments
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2011-10-31 17:18:16

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.

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

The bottom line is that I want to be able to write generic code with atomics 
which transparently works on many platforms. I may be able to tune it on one 
or two platforms that are important to me right now but the code may work just 
as well on others. If it works slower, too bad, but it still works - it's 
better than nothing. If a better platform-specific code can be written in this 
case, and there is someone willing to write it - no problem, let him do that.

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