C - Могут ли глобальные указатели быть изменены разными потоками?

Самым большим источником хитростей являются согласованность памяти и согласованность памяти.

Согласованность описывает, что происходит, когда поток A записывает в G, а поток B пытается прочитать его почти в один и тот же момент. Представьте, что поток A и B находится на разных процессорах (давайте также назовем их A и B для простоты). Когда A записывает в переменную, между ним и памятью, которую видит поток B, существует множество схем. Во-первых, A, вероятно, напишет на количество сигналов, которые должны идти вперед и назад по проводам и конденсаторов и транзисторов и сложный диалог между кешем и основным блоком памяти. Между тем, у B есть собственный кеш. Когда изменения происходят в основной памяти, B может не сразу их увидеть, по крайней мере, до тех пор, пока не заполнит свой кэш из этой строки. И так далее. В общем, может пройти много микросекунд, прежде чем изменение потока A станет видимым для B.

Согласованность описывает, что происходит, когда A записывает в переменную G, а затем в переменную H. Если он считывает эти переменные, он увидит, что записи происходят в этом порядке. Но поток B может видеть их в другом порядке, в зависимости от того, очищается ли сначала H из кеша обратно в основную оперативную память. И что произойдет, если и A, и B одновременно пишут в G (по настенным часам), а затем попытаются прочитать ответ из Это? Какое значение они увидят?

Согласованность и согласованность обеспечиваются на многих процессорах с помощью операций барьер памяти. Например, PowerPC имеет синхронизацию код операции, который гласит: «Гарантия того, что любая запись, сделанная любым потоком в основную память, будет видна при любом чтении после этой операции синхронизации». (в основном это делается путем перепроверки каждой строки кэша относительно основной ОЗУ.) Архитектура Intel делает это до некоторой степени автоматически, если вы заранее предупредите его, что« эта операция затрагивает синхронизированную память ».

Тогда у вас возникнет проблема переупорядочения компилятора. Вот где код

int foo( int *e, int *f, int *g, int *h) 
{
   *e = *g;
   *f = *h;
   // <-- another thread could theoretically write to g and h here
   return *g + *h ;
}

может быть внутренне преобразован компилятором во что-то вроде

int bar( int *e, int *f, int *g, int *h) 
{
  int b = *h;
  int a = *g;
  *f = b ;
  int result = a + b;
  *e = a ;
  return result;
}

что может дать вам совершенно другой результат, если другой поток выполнит запись в указанном выше месте! также обратите внимание на то, что записи выполняются в другом порядке в bar. Это проблема, которую должен решить volatile - он не позволяет компилятору сохранять значение *g в локальном, но вместо этого заставляет его перезагружать это значение из памяти каждый раз, когда он видит *g.

Как видите, этого недостаточно для обеспечения согласованности и согласованности памяти на многих процессорах. Это действительно было изобретено для случаев, когда у вас был один процессор, который пытался читать с оборудования с отображением в память - например, последовательный порт, где вы хотите смотреть на место в памяти каждые n микросекунд, чтобы увидеть какое значение в настоящее время находится в сети. (Именно так I / O работал, когда они изобрели C.)

Что с этим делать? Как я уже сказал, на эту тему есть целые книги. Но краткий ответ заключается в том, что вы, вероятно, захотите использовать средства, которые ваша операционная система / платформа времени выполнения предоставляет для синхронизированной памяти.

Например, Windows предоставляет API доступа к заблокированной памяти, чтобы дать вам четкий способ обмена данными между потоками A и B. GCC пытается предоставить некоторые похожие функции. Строительные блоки потоковой передачи Intel предоставляют вам удобный интерфейс для платформ x86 / x64 и библиотека поддержки потоков C ++ 11 также предоставляет некоторые возможности.