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