Что подразумевается под & ldquo; потокобезопасным & rdquo; код?

Как уже отмечали другие, безопасность потоков означает, что фрагмент кода будет работать без ошибок, если он используется более чем одним потоком одновременно.

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

Например, Java имеет два класса, которые почти эквивалентны, StringBuffer и StringBuilder. Разница в том, что StringBuffer является потокобезопасным, поэтому один экземпляр StringBuffer может использоваться несколькими потоками одновременно. StringBuilder не является поточно-ориентированным и разработан как замена с более высокой производительностью для тех случаев (подавляющего большинства), когда строка строится только одним потоком.

Мне нравится определение из Java-параллелизма Брайана Гетца на практике из-за его полноты

«Класс является поточно-ориентированным, если он ведет себя правильно при доступе из нескольких потоков, независимо от планирования или чередования выполнения эти потоки в среде выполнения и без дополнительной синхронизации или другой координации со стороны вызывающего кода. "

Просто - код будет работать нормально, если многие потоки исполняют этот код одновременно.

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

totalRequests = totalRequests + 1
MOV EAX, [totalRequests]   // load memory for tot Requests into register
INC EAX                    // update register
MOV [totalRequests], EAX   // store updated value back to memory

1. Первое условие - наличие областей памяти, доступных из нескольких потоков. Как правило, эти местоположения являются глобальными / статическими переменными или могут быть доступны из кучи в глобальных / статических переменных. Каждый поток получает свой собственный кадр стека для локальных переменных в области функций / методов, поэтому эти локальные переменные функции / метода otoh (которые находятся в стеке) доступны только из одного потока, которому принадлежит этот стек.
2. Вторым условием является то, что существует свойство (часто называемое инвариантом ), которое связано с этими общими ячейками памяти, которые должны быть истинными или действительными, чтобы программа функционировала правильно. В приведенном выше примере свойство заключается в том, что « totalRequests должно точно представлять общее количество раз, когда какой-либо поток выполнял какую-либо часть инструкции приращения ». Как правило, это свойство инварианта должно содержать значение true (в этом случае totalRequests должно содержать точное число), прежде чем произойдет обновление, чтобы обновление было корректным.
3. Третье условие заключается в том, что свойство инварианта НЕ выполняется во время какой-либо части фактического обновления. (Это временно недействительно или ложно во время некоторой части обработки). В этом конкретном случае, с момента получения totalRequests до момента сохранения обновленного значения, totalRequests не не не удовлетворяет инварианту.
4. Четвертое и последнее условие, которое должно произойти для гонки (и, следовательно, для кода НЕ быть «поточно-ориентированным»), заключается в том, что другой поток должен быть в состоянии чтобы получить доступ к общей памяти , а инвариант нарушается, вызывая, таким образом, непоследовательное или неправильное поведение.

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

http://mindprod.com/jgloss/threadsafe.html

Для завершения других ответов:

Синхронизация вызывает беспокойство только тогда, когда код в вашем методе выполняет одно из двух действий:

1. работает с некоторым внешним ресурсом, который не является потоком безопасный.
2. Считывает или изменяет постоянный объект или поле класса

Это означает, что переменные, определенные в вашем методе, всегда являются потокобезопасными. Каждый вызов метода имеет свою версию этих переменных. Если метод вызывается другим потоком или тем же потоком, или даже если метод вызывает сам себя (рекурсия), значения этих переменных не разделяются.

Планирование потоков не гарантируется как циклический перебор . Задача может полностью перегружать процессор за счет потоков с одинаковым приоритетом. Вы можете использовать Thread.yield (), чтобы иметь совесть. Вы можете использовать (в Java) Thread.setPriority (Thread.NORM_PRIORITY-1), чтобы понизить приоритет потока

Плюс, остерегайтесь:

• больших затрат времени выполнения (уже упоминавшихся другими ) в приложениях, которые перебирают эти «потокобезопасные» структуры.
• Thread.sleep (5000) должен спать в течение 5 секунд. Однако, если кто-то изменит системное время, вы можете спать очень долго или вообще не спать. ОС записывает время пробуждения в абсолютной форме, а не в относительной.

Не путайте безопасность потоков с детерминизмом. Потокобезопасный код также может быть недетерминированным. Учитывая сложность отладки проблем с многопоточным кодом, это, вероятно, нормальный случай. : -)

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

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

Мне нравится определение, данное в Java Concurrency in Practice :

[Часть кода] является поточно-ориентированной, если она ведет себя правильно при доступе из нескольких потоков, независимо от того, планирования или чередования выполнения этих потоков средой выполнения и без дополнительной синхронизации или другой координации со стороны вызывающего кода.

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

Придуманный пример

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

• counter.next() никогда не возвращает значение, которое уже было возвращено ранее (для простоты мы не предполагаем переполнения и т. Д.)
• все значения из 0 к текущему значению были возвращены на каком-то этапе (значение не пропускается)

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

_{Примечание: кросс-пост на программистов}

Да и нет.

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

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

По крайней мере, в C++, я думаю ориентированный на многопотоковое исполнение как что-то вроде неправильного употребления, в котором он упускает много из имени. Чтобы быть ориентированным на многопотоковое исполнение, код обычно должен быть превентивный об этом. Это обычно не пассивное качество.

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

И это - то, почему некоторые люди предпочитают использовать термин , внутренне синхронизировался .

Наборы Терминологии

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

1. ориентированный на многопотоковое исполнение
2. не ориентированный на многопотоковое исполнение

второе (и лучше):

1. доказательство потока
2. распараллеливает совместимый
3. , распараллеливают враждебный

, одна треть:

1. внутренне синхронизировался
2. , внешне синхронизировался
3. аналогии unsynchronizeable

ориентированный на многопотоковое исполнение ~ доказательство потока , ~ внутренне синхронизировался

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

не ориентированный на многопотоковое исполнение (но хороший) ~ распараллеливают совместимый , ~ внешне синхронизировался

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

не ориентированный на многопотоковое исполнение (и плохо) ~ распараллеливают враждебный ~ unsynchronizeable

пример враждебный к потоку , система - при вхождении в отношения с кем-то, кто изменяет Вам, потому что, даже если Вам говорят, у Вас есть эксклюзивный доступ к ним глубоко, это не верно, и доверительный повреждается. Повреждение "данных" включено. Разрешение почти невозможно, потому что система становится не детерминированной, ведя к разбивке значения в межличностном общении, точно так же, как с потоками. Этот шаблон может также считаться более широко [1 127] антиобщественный, , который я предпочитаю, потому что это менее характерно для потоков и так в более общем плане применимо ко многим областям программирования.