Boost logo

Boost :

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

On Monday, October 31, 2011 15:01:35 Helge Bahmann wrote:
> a) IMHO atomics for inter-process coordination is the exception, while
> inter-thread coordination is the norm

I have to disagree. Atomics may be used to communicate processes just as well
as threads, if not better. I often use atomics to perform lock-free IPC
between processes. Aside from performance reasons, this often adds to
application resillience to process crashes, when classic primitives like mutex
may be left in an invalid state. Multi-process applications (with shared
memory to communicate between processes) are less common than other kinds of
applications, yes. But that doesn't make this use case exceptional in any way.

> b) "per-object" lock is expensive (sizeof(pthread_mutex_t) can be 40 bytes)
> c) when you hit the fallback path, then you are better off using a
> datastructure with locking to begin with
> *If* I change the implementation to a per-object lock then this would in my
> view mean to optimize for an uncommon case, with noticable memory overhead
> penalties for the common case, to allow using the atomic objects as
> "drop-in" replacements in an environment where they are not the best
> solution anyways. (I would favor to move the distinction between using
> atomic objects for a given data structure versus locking upwards, instead
> of moving everything downwards and shoe-horning it into boost.atomic).

Well, yes and no. Consider this example, which illustrates the control
structure of a lock-free ring buffer:

  struct index_t
    uint32_t version;
    uint32_t index;

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.

On the other hand, I agree that there is no sense in atomic< std::string > or
something like that. But hey, nothing prevents you from shooting in your foot.

> I have serious difficulties justifying such a change, maybe others can offer
> their opinion?

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at