Я услышал, что я ++ не ориентирован на многопотоковое исполнение, ++ я ориентирован на многопотоковое исполнение?

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

Не зная язык, ответ должен протестировать heck из него.

Стандарт C++ 1998 года не имеет ничего для высказывания о потоках, хотя следующий стандарт (должный в этом году или следующее) делает. Поэтому Вы не можете сказать ничего интеллектуального о потокобезопасности операций, не обращаясь к реализации. Это не просто используемый процессор, но и комбинация компилятора, ОС и модели потока.

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

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

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

Править: Я просто искал этот конкретный вопрос, и инкремент на X86 является атомарным в единственных системах процессора, но не в многопроцессорных системах. Используя блокировку префикс может сделать это атомарным, но это намного более портативно только для использования InterlockedIncrement.

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

Поскольку другие указали: необходимо защитить любой многопоточный доступ к переменным платформой определенные вызовы.

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

На x86/Windows в C/C++ Вы не должны предполагать, что это ориентировано на многопотоковое исполнение. Необходимо использовать InterlockedIncrement () и InterlockedDecrement () при требовании атомарных операций.

Если Вы хотите атомарный инкремент в C++, можно использовать C++ 0x библиотеки ( std::atomic тип данных) или что-то как TBB.

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

Разъяснить "обновляющий тип данных с одним словом" комментарий:

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

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

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

ПРИМЕЧАНИЕ. В моем исходном ответе также было сказано, что архитектура Intel 64 битов была повреждена имея дело с данными на 64 бита. Это не верно, таким образом, я отредактировал ответ, но мое редактирование утверждало, что микросхемы PowerPC были повреждены. Это верно при чтении непосредственных значений (т.е. константы) в регистры (см. два раздела, названные, "Загружая указатели" в соответствии со списком 2 и списком 4). Но существует инструкция для загрузки данных из памяти в одном цикле (lmw), таким образом, я удалил ту часть своего ответа.

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

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

Они оба небезопасны потоком.

ЦП не может сделать математики непосредственно с памятью. Это делает это косвенно путем загрузки значения из памяти и выполнения математики с регистрами ЦП.

я ++

register int a1, a2;

a1 = *(&i) ; // One cpu instruction: LOAD from memory location identified by i;
a2 = a1;
a1 += 1; 
*(&i) = a1; 
return a2; // 4 cpu instructions

++ я

register int a1;

a1 = *(&i) ; 
a1 += 1; 
*(&i) = a1; 
return a1; // 3 cpu instructions

Для обоих случаев существует состояние состязания, которое приводит к непредсказуемому, которое я оцениваю.

Например, давайте предположим, что существует два параллельных ++, я распараллеливаю с каждым a1 регистра использования, b1 соответственно. И, с контекстным переключением, выполняемым как следующее:

register int a1, b1;

a1 = *(&i);
a1 += 1;
b1 = *(&i);
b1 += 1;
*(&i) = a1;
*(&i) = b1;

В результате я не становлюсь i+2, это становится i+1, который является неправильным.

Для исправления этого, moden центральные процессоры обеспечивают некоторую БЛОКИРОВКУ, РАЗБЛОКИРОВАЛИ инструкции по CPU во время интервала, контекстное переключение отключено.

На Win32 используйте InterlockedIncrement (), чтобы сделать меня ++ для потокобезопасности. Это намного быстрее, чем доверие взаимному исключению.

Вы не можете сделать общий оператор или о ++ я или о я ++. Почему? Рассмотрите постепенное увеличение 64-разрядного целого числа в 32-разрядной системе. Если базовая машина не имеет квадратическое слово "загрузка, инкремент, хранилище" инструкция, увеличивая то значение собирается потребовать многоадресных команд, любая из которых может быть прервана контекстным переключением потока.

Кроме того, ++i не всегда, "добавьте тот к значению". На языке как C, увеличивая указатель на самом деле добавляет, что размер вещи указал. Таким образом, если i указатель на 32 байтовых структуры, ++i добавляют 32 байта. Принимая во внимание, что почти все платформы имеют "инкрементное значение в адресе памяти" инструкция, которая является атомарной, не у всех есть атомарное, "добавьте произвольное значение для оценки в адрес памяти" инструкции.

Взгляните на сравнение, сделанное недавно разработчиками Python: http://wiki.python.org/moin/DvcsComparison . Они выбрали Mercurial по трем важным причинам:

Выбор в пользу Mercurial был сделан по трем важным причинам:

• Согласно небольшому опросу, разработчики Python больше заинтересованы в использовании Mercurial. t гарантировать, что остальная часть вычислений будет согласованной, если вы не используете правильные блокировки.

  Если вы хотите поэкспериментировать самостоятельно, напишите программу, в которой N потоков одновременно увеличивают общую переменную M раз каждый ... if значение меньше N * M, то некоторое приращение было перезаписано. Попробуйте и с преинкрементом, и с постинкрементом и сообщите нам; -)

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

Вот она в Java:

public class IntCompareAndSwap {
    private int value = 0;

    public synchronized int get(){return value;}

    public synchronized int compareAndSwap(int p_expectedValue, int p_newValue){
        int oldValue = value;

        if (oldValue == p_expectedValue)
            value = p_newValue;

        return oldValue;
    }
}

public class IntCASCounter {

    public IntCASCounter(){
        m_value = new IntCompareAndSwap();
    }

    private IntCompareAndSwap m_value;

    public int getValue(){return m_value.get();}

    public void increment(){
        int temp;
        do {
            temp = m_value.get();
        } while (temp != m_value.compareAndSwap(temp, temp + 1));

    }

    public void decrement(){
        int temp;
        do {
            temp = m_value.get();
        } while (temp > 0 && temp != m_value.compareAndSwap(temp, temp - 1));

    }
}

Бросить i в локальное хранилище потока; это не атомарно, но тогда это не имеет значения.

Даже если он сокращается до одной инструкции сборки, увеличивая значение непосредственно в памяти, он все равно не является потокобезопасным.

При увеличении значения в памяти аппаратное обеспечение выполняет операцию «чтение-изменение-запись»: оно считывает значение из памяти, увеличивает его и записывает обратно в память. Аппаратное обеспечение x86 не имеет возможности увеличения непосредственно в памяти; ОЗУ (и кеши) может только читать и сохранять значения, но не изменять их.

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

Есть способ избежать этой проблемы; Процессоры x86 (и большинство многоядерных процессоров, которые вы найдете) способны обнаруживать этот вид конфликта в оборудовании и упорядочивать его, так что вся последовательность чтения-изменения-записи выглядит атомарной. Однако, поскольку это очень дорого, это делается только по запросу кода, на x86 обычно через префикс LOCK . Другие архитектуры могут делать это другими способами с аналогичными результатами; например, связанное с загрузкой / сохранение-условное и атомарное сравнение и замена (последние процессоры x86 также имеют этот последний).

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

Лучше всего использовать атомарные примитивы (если они есть в вашем компиляторе или библиотеках) или выполнять приращение непосредственно в сборке (используя правильные атомарные инструкции).