C++ Thread, общие данные

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

volatile int myInteger;

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

Помимо прочего, ваше решение будет использовать 100% ЦП. Google по запросу "условная переменная".

Крис Джестер-Янг отметил, что:

This only work under Java 1.5+'s memory model. The C++ standard does not address threading, and volatile does not guarantee memory coherency between processors. You do need a memory barrier for this

в таком случае единственный верный ответ - это реализация системы синхронизации, не так ли?

Вот пример, в котором используются переменные условия повышения:

bool _updated=false;
boost::mutex _access;
boost::condition _condition;

bool updated()
{
  return _updated;
}

void thread1()
{
  boost::mutex::scoped_lock lock(_access);
  while (true)
  {
    boost::xtime xt;
    boost::xtime_get(&xt, boost::TIME_UTC);
    // note that the second parameter to timed_wait is a predicate function that is called - not the address of a variable to check
    if (_condition.timed_wait(lock, &updated, xt))
      updateScreen();
    doSomethingElse();
  }
}

void thread2()
{
  while(true)
  {
    if (doSomething())
      _updated=true;
  }
}

Если область видимости правильная («внешняя», глобальная и т. д.), То изменение будет замечено. Вопрос в том, когда? И в каком порядке?

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

На самом деле это не отображается в вашем конкретном примере, потому что нет никаких других инструкций вокруг вашего присваивания, но представьте, что функции, объявленные после вашего bool assign, выполняют перед присваивания.

Загляните в Опасность трубопроводов в Википедии или поищите в Google по запросу "изменение порядка инструкций компилятора"

Используйте замок. Всегда всегда используйте блокировку для доступа к общим данным. Пометка переменной как изменчивой не позволит компилятору оптимизировать чтение из памяти, но не предотвратит другие проблемы, такие как переупорядочение памяти. Без блокировки нет гарантии, что данные, записанные в doSomething (), будут видны в функции updateScreen ().

Единственный другой безопасный способ - использовать забор памяти, явно или неявно, например, с помощью функции Interlocked *.

Как уже говорили другие, ключевое слово volatile - ваш друг. :-)

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

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

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

При всем вышесказанном вы можете получить лучшие результаты (как указано в Джефф) за счет использования семафора или условной переменной.

Этот - разумное введение в предмет.

Да. Нет. Может быть.

Во-первых, как уже упоминалось другими, вам нужно сделать dataUpdated изменчивым; в противном случае компилятор может освободить чтение из цикла (в зависимости от того, видит ли он, что doSomethingElse его не касается).

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

Летучие вещества считаются вредными и Барьеры памяти ядра Linux - хороший фон по основным проблемам; Я не знаю ничего подобного, написанного специально для многопоточности. К счастью, потоки не вызывают этих проблем почти так часто, как аппаратные периферийные устройства, хотя описываемый вами тип случая (флаг, указывающий на завершение, с другими данными, которые считаются действительными, если этот флаг установлен), является именно тем, что требует упорядочивания. материя ...

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

volatile int myInteger;

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

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

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

Атомарность действительно важна как для однопроцессорных, так и для многопроцессорных платформ. Проблема возникает из-за того, что переменная, вероятно, имеет многобайтовый характер, и вопрос в том, может ли один поток видеть частичное обновление значения или нет. т.е.: изменены некоторые байты, переключение контекста, недопустимое значение, прочитанное прерывающим потоком. Для одной переменной, которая имеет размер машинного слова или меньше и естественно выровнена, не должно быть проблемой. В частности, тип int всегда должен быть в порядке в этом отношении, пока он выровнен - ​​что должно быть случаем по умолчанию для компилятора.

Что касается согласованности, это потенциальная проблема в многопроцессорной системе. Вопрос в том, реализует ли система полную когерентность кеша между процессорами или нет. Если реализовано, это обычно делается с помощью протокола MESI на оборудовании. В вопросе не говорится о платформах, но как платформы Intel x86, так и платформы PowerPC имеют согласованный кэш между процессорами для обычно отображаемых областей данных программы. Поэтому проблемы этого типа не должны беспокоить при обычном доступе к памяти данных между потоками, даже если имеется несколько процессоров.

Последняя проблема, связанная с атомарностью, связана с атомарностью чтения-изменения-записи. То есть, как вы гарантируете, что если значение считывается, обновляется по значению и записывается, что это происходит атомарно, даже между процессорами, если их больше одного. Итак, для того, чтобы это работало без определенных объектов синхронизации, потребовалось бы, чтобы все потенциальные потоки, обращающиеся к переменной, были ТОЛЬКО читателями, но ожидайте, что только один поток может когда-либо быть писателем одновременно. Если это не так, то вам действительно нужен доступный объект синхронизации, чтобы иметь возможность гарантировать атомарные действия при действиях чтения-изменения-записи для переменной.