Re: [boost] [atomic] comments

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