Реализация глобального общего счетчика - PullRequest
0 голосов
/ 05 мая 2019

следующий код взят из (Листинг 5.3): Трудно ли параллельное программирование, и, если да, что вы можете с этим поделать?

DEFINE PER_THREAD(long, counter);

void inc_count(void){
  __get_thread_var(counter)++; // __get_thread_var returns a reference to thread local counter.  
}

long read_count(void){
    int t;
    long sum = 0;

    for_each_thread(t)
       sum += per_thread(counter, t);
    return sum;
}

Над кодом реализован глобальный(общий для ядер) counter.Мы могли бы вместо этого использовать атомарные операции.Однако мы рассмотрим случай, когда обновления происходят очень часто, поэтому нам нужна переменная для каждого потока, чтобы минимизировать трафик в системе ЦП.

Я не могу понять, почему это правильно.В конце концов, в C/C++/Java мы имеем самое большее SC-DRF (последовательная согласованность, если нет гонки данных).

На самом деле, у нас есть данные.В результате у нас нет никаких гарантий от модели памяти.Особенно, что насчет Out Of Air Thin values?Я не вижу, как это гарантировано, что этого не произойдет.Так что ты думаешь?Верна ли эта реализация с точки зрения моих сомнений и почему?

1 Ответ

2 голосов
/ 05 мая 2019

Не уверен, на какую версию документа вы ссылаетесь, но на рисунке 5.3 в последней используются макросы READ_ONCE и WRITE_ONCE, которые обеспечивают базовые гарантии видимости между потоками.В сочетании с правильным выравниванием counter, я полагаю, что это, по сути, эквивалент расслабленной атомарной семантики.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...