Последствия производительности волатильных функций-членов

Я нашел статью 2001 года о докторе д-ра Доббса: volatile - многопоточный программист Лучший друг. Я всегда считал "volatile" несколько бесполезным - по крайней мере, как классификатор для переменных - поскольку доступ к переменным, разделяемым между потоками, всегда проходит через какой-то слой библиотеки.

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

Чтобы резюмировать статью быстро, основная идея - объявить класс следующим образом:

struct SomeObject {
  void SingleThreadedMethod();
  void Method();
  void Method() volatile;
};

И затем, экземпляры класса, например:

// An object that will only be accessed from a single thread.
SomeObject singleThreaded;
// An objecect that will be accessed from multiple threads.
volatile SomeObject sharedObject;

sharedObject.SingleThreadedMethod(); //this will be an compile error
sharedObject.Method(); // will call the volatile overload of Method
singleThreaded.Method(); // would call the non volatile overload of Method.

Идея заключается в том, что будут реализованы такие методы, как "Метод() volatile":

void SomeObject::Method() volatile {
  enter_critical_section();
  const_cast<Method*>(this)->Method();
  leave_critical_Section();
}

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

Мой вопрос об этом подходе заключается в следующем: каковы последствия для производительности "летучих" квалифицированных методов? Является ли компилятор вынужден предположить, что все переменные, к которым обращаются в энергозависимой функции, должны рассматриваться как неустойчивые и, следовательно, исключены из возможностей оптимизации? Исключить ли локальные переменные из оптимизации? Это может быть большой перетасовкой производительности при любой изменчивой квалифицированной функции-члена, если это так.

Ответ 1