Может быть volatile в определяемых пользователем типах, чтобы облегчить написание ориентированного на многопотоковое исполнение кода.

Я думаю, что проблема не в потокобезопасности, обеспечиваемой volatile. Это не так, и в статье Андрея об этом не говорится. Здесь для этого используется mutex. Вопрос в том, является ли использование volatilekeyword для обеспечения статической проверки типов наряду с использованием мьютекса для потокобезопасного кода злоупотреблением ключевым словом volatile? ИМХО, это довольно умно, но я встречал разработчиков, которые не являются поклонниками строгой проверки типов только ради этого.

IMO, когда вы пишете код для многопоточной среды, уже достаточно осторожности, чтобы подчеркнуть, что вы ожидаете, что люди не будут игнорировать условия гонки и взаимоблокировки.

Недостатком этого подхода с оболочкой является то, что каждая операция над типом, заключенным с использованием LockingPtr, должна выполняться через функцию-член. Это повысит один уровень косвенности, что может значительно повлиять на удобство разработчиков в команде.

Но если вы пурист, который верит в дух C++, известный как строгая проверка типов; это хорошая альтернатива.

Это перехватывает некоторые виды кода, небезопасного для потоков (параллельный доступ), но пропускает другие (взаимоблокировки из-за инверсии блокировки). Ни то, ни другое не особенно легко проверить, так что это скромная частичная победа. На практике не забыть ввести ограничение, согласно которому доступ к определенному частному члену возможен только при определенной блокировке, для меня не было большой проблемой.

Два ответа на этот вопрос продемонстрировали, что вы правы, говоря, что путаница является значительным недостатком - сопровождающие, возможно, были настолько сильно обусловлены пониманием того, что семантика доступа к памяти volatile не имеет ничего общего с потокобезопасностью, что они даже не будут прочитайте остальную часть кода/статьи, прежде чем объявить ее неправильной.

Я думаю, что другим большим недостатком, описанным Александреску в статье, является то, что он не работает с неклассовыми типами. Это может быть трудным для запоминания ограничением. Если вы считаете, что пометка ваших элементов данных volatile не позволяет вам использовать их без блокировки, а затем ожидаете, что компилятор сообщит вам, когда блокировать, то вы можете случайно применить это к int или к члену типа, зависящего от параметра шаблона. Полученный неверный код будет успешно скомпилирован, но вы, возможно, перестали проверять свой код на наличие ошибок такого рода. Представьте себе ошибки, которые возникли бы, особенно в коде шаблона, если бы можно было присвоить const int, но программисты тем не менее ожидали, что компилятор проверит для них const-корректность...

Я думаю, что риск того, что тип члена данных на самом деле имеет какие-либо volatile функции-члена, следует отметить, а затем сбросить со счетов, хотя когда-нибудь это может кого-то укусить.

Интересно, есть ли что-нибудь, что можно сказать о компиляторах, предоставляющих дополнительные модификаторы типа в стиле const через атрибуты. Страуструп говорит: "Рекомендуется использовать атрибуты контролировать только то, что не влияет на смысл программы, но может помочь обнаружить ошибки». Если бы вы могли заменить все упоминания volatile в коде на [[__typemodifier(needslocking)]], то, думаю, было бы лучше. Тогда было бы невозможно использовать объект без const_cast, и, надеюсь, вы не написали бы const_cast, не подумав о том, что именно вы отбрасываете.

C++03 §7.1.5.1p7:

Если предпринимается попытка сослаться на объект, определенный с типом с уточнением volatile, посредством использования lvalue с типом с уточнением volatile, поведение программы не определено.

Поскольку buffer_ в вашем примере определен как volatile, его отбрасывание является неопределенным поведением. Однако вы можете обойти это с помощью адаптера, который определяет объект как энергонезависимый, но добавляет изменчивость:

template<class T>
struct Lock;

template<class T, class Mutex>
struct Volatile {
  Volatile() : _data () {}
  Volatile(T const &data) : _data (data) {}

  T        volatile& operator*()        { return _data; }
  T const  volatile& operator*() const  { return _data; }

  T        volatile* operator->()        { return &**this; }
  T const  volatile* operator->() const  { return &**this; }

private:
  T _data;
  Mutex _mutex;

  friend class Lock<T>;
};

Дружба нужна для жесткого контроля энергонезависимого доступа через уже заблокированный объект:

template<class T>
struct Lock {
  Lock(Volatile<T> &data) : _data (data) { _data._mutex.lock(); }
  ~Lock() { _data._mutex.unlock(); }

  T& operator*() { return _data._data; }
  T* operator->() { return &**this; }

private:
  Volatile<T> &_data;
};

Пример:

struct Something {
  void action() volatile;  // Does action in a thread-safe way.
  void action();  // May assume only one thread has access to the object.
  int n;
};
Volatile<Something> data;
void example() {
  data->action();  // Calls volatile action.
  Lock<Something> locked (data);
  locked->action();  // Calls non-volatile action.
}

Есть два предостережения. Во-первых, вы по-прежнему можете обращаться к общедоступным элементам данных (Something::n), но они будут квалифицированы как volatile; это, вероятно, потерпит неудачу в разных точках. И, во-вторых, Что-то не знает, действительно ли оно было определено как volatile, и отбрасывание этого volatile (из «этого» или из членов) в методах все равно будет UB, если оно было определено таким образом:

Something volatile v;
v.action();  // Compiles, but is UB if action casts away volatile internally.

Основная цель достигнута: объекты не должны знать, что они используются таким образом, а компилятор предотвратит вызовы энергонезависимых методов (а это все методы для большинства типов), если только вы явно не пройдете блокировку.

Основываясь на другого кода и полностью устраняя необходимость в спецификаторе volatile, это не только работает, но и правильно распространяет const (аналогично iterator vs const_iterator). К сожалению, для двух типов интерфейса требуется довольно много стандартного кода, но вам не нужно повторять какую-либо логику методов: каждый из них по-прежнему определяется один раз, даже если вам нужно аналогичным образом «дублировать» «изменчивые» версии. к обычной перегрузке методов на константные и неконстантные.

#include <cassert>
#include <iostream>

struct ExampleMutex {  // Purely for the sake of this example.
  ExampleMutex() : _locked (false) {}
  bool try_lock() {
    if (_locked) return false;
    _locked = true;
    return true;
  }
  void lock() {
    bool acquired = try_lock();
    assert(acquired);
  }
  void unlock() {
    assert(_locked);
    _locked = false;
  }
private:
  bool _locked;
};

// Customization point so these don't have to be implemented as nested types:
template<class T>
struct VolatileTraits {
  typedef typename T::VolatileInterface       Interface;
  typedef typename T::VolatileConstInterface  ConstInterface;
};

template<class T>
class Lock;
template<class T>
class ConstLock;

template<class T, class Mutex=ExampleMutex>
struct Volatile {
  typedef typename VolatileTraits<T>::Interface       Interface;
  typedef typename VolatileTraits<T>::ConstInterface  ConstInterface;

  Volatile() : _data () {}
  Volatile(T const &data) : _data (data) {}

  Interface       operator*()        { return _data; }
  ConstInterface  operator*() const  { return _data; }
  Interface       operator->()        { return _data; }
  ConstInterface  operator->() const  { return _data; }

private:
  T _data;
  mutable Mutex _mutex;

  friend class Lock<T>;
  friend class ConstLock<T>;
};

template<class T>
struct Lock {
  Lock(Volatile<T> &data) : _data (data) { _data._mutex.lock(); }
  ~Lock() { _data._mutex.unlock(); }

  T& operator*() { return _data._data; }
  T* operator->() { return &**this; }

private:
  Volatile<T> &_data;
};

template<class T>
struct ConstLock {
  ConstLock(Volatile<T> const &data) : _data (data) { _data._mutex.lock(); }
  ~ConstLock() { _data._mutex.unlock(); }

  T const& operator*() { return _data._data; }
  T const* operator->() { return &**this; }

private:
  Volatile<T> const &_data;
};

struct Something {
  class VolatileConstInterface;
  struct VolatileInterface {
    // A bit of boilerplate:
    VolatileInterface(Something &x) : base (&x) {}
    VolatileInterface const* operator->() const { return this; }

    void action() const {
      base->_do("in a thread-safe way");
    }

  private:
    Something *base;

    friend class VolatileConstInterface;
  };

  struct VolatileConstInterface {
    // A bit of boilerplate:
    VolatileConstInterface(Something const &x) : base (&x) {}
    VolatileConstInterface(VolatileInterface x) : base (x.base) {}
    VolatileConstInterface const* operator->() const { return this; }

    void action() const {
      base->_do("in a thread-safe way to a const object");
    }

  private:
    Something const *base;
  };

  void action() {
    _do("knowing only one thread accesses this object");
  }

  void action() const {
    _do("knowing only one thread accesses this const object");
  }

private:
  void _do(char const *restriction) const {
    std::cout << "do action " << restriction << '\n';
  }
};

int main() {
  Volatile<Something> x;
  Volatile<Something> const c;

  x->action();
  c->action();

  {
    Lock<Something> locked (x);
    locked->action();
  }

  {
    ConstLock<Something> locked (x);  // ConstLock from non-const object
    locked->action();
  }

  {
    ConstLock<Something> locked (c);
    locked->action();
  }

  return 0;
}

Сравните class Something с тем, что потребовало бы использование volatile Александреску:

struct Something {
  void action() volatile {
    _do("in a thread-safe way");
  }

  void action() const volatile {
    _do("in a thread-safe way to a const object");
  }

  void action() {
    _do("knowing only one thread accesses this object");
  }

  void action() const {
    _do("knowing only one thread accesses this const object");
  }

private:
  void _do(char const *restriction) const volatile {
    std::cout << "do action " << restriction << '\n';
  }
};

Посмотрите на это с другой точки зрения. Когда вы объявляете переменную как константу, вы сообщаете компилятору, что значение не может быть изменено вашим кодом. Но это не означает, что значение не изменится. Например, если вы сделаете это:

const int cv = 123;
int* that = const_cast<int*>(&cv);
*that = 42;

... это вызывает неопределенное поведение в соответствии со стандартом, но на практике что-то произойдет. Возможно, значение будет изменено. Возможно, будет сигфоул. Может быть, запустится авиасимулятор — кто знает. Дело в том, что вы не знаете независимо от платформы, что произойдет. Итак, очевидное обещание const не выполнено. Значение может быть, а может и не быть константой.

Теперь, учитывая, что это правда, является ли использование const злоупотреблением языком? Конечно, нет. Это по-прежнему инструмент, который язык предоставляет, чтобы помочь вам писать лучший код. Он никогда не будет универсальным инструментом, обеспечивающим неизменность значений — в конечном счете этим инструментом является мозг программиста, — но делает ли это const бесполезным?

Я говорю нет, использование const в качестве инструмента, помогающего вам писать лучший код, не является злоупотреблением языком. На самом деле я бы сделал еще один шаг и сказал, что это намерение этой функции.

То же самое относится и к volatile. Объявление чего-либо изменчивым не сделает вашу программу потокобезопасной. Вероятно, это даже не сделает эту переменную или объект потокобезопасным. Но компилятор будет применять семантику CV-квалификации, и осторожный программист может использовать этот факт, чтобы помочь ему написать более качественный код, помогая компилятору определить места, где он может написать ошибку. Так же, как компилятор помогает ему, когда он пытается это сделать:

const int cv = 123;
cv = 42;  // ERROR - compiler complains that the programmer is potentially making a mistake

Забудьте о границах памяти и атомарности изменчивых объектов и переменных, точно так же, как вы давно забыли об истинной константности cv. Но используйте инструменты, которые дает вам язык, чтобы писать лучший код. Одним из таких инструментов является volatile.

Вам лучше этого не делать. volatile даже не был изобретен для обеспечения потокобезопасности. Он был изобретен для правильного доступа к отображаемым в памяти аппаратным регистрам. Ключевое слово volatile не влияет на функцию внеочередного выполнения ЦП. Вы должны использовать правильные вызовы ОС или инструкции CAS, определенные ЦП, ограничения памяти и т. д.

CAS

Забор памяти

В статье ключевое слово используется скорее как тег required_thread_safety, чем как фактическое предполагаемое использование volatile.

Не прочитав статью — почему тогда Андрей не использует указанный тег required_thread_safety? Злоупотребление volatile здесь звучит не очень хорошо. Я считаю, что это вызывает больше путаницы (как вы сказали), а не избегает ее.

Тем не менее, volatile иногда может потребоваться в многопоточном коде, даже если это не достаточное условие, просто для того, чтобы компилятор не оптимизировал проверки, основанные на асинхронном обновлении значения.

Я не знаю конкретно, разумен ли совет Александреску, но, несмотря на то, что я уважаю его как супер-умного чувака, его трактовка семантики volatile предполагает, что он вышел далеко за пределы своей области знаний. Volatile не имеет абсолютно никакой ценности в многопоточности (см. " rel="nofollow noreferrer">здесь для хорошего рассмотрения предмета), и поэтому утверждение Александреску о том, что volatile пригодно для многопоточного доступа, заставляет меня серьезно задуматься, насколько я могу доверять в остальной части его статьи.