Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Объясните, зачем все эти пляски с многопоточностью, если можно использовать lock-free?
|
|||
|---|---|---|---|
|
#18+
Конечно, есть ситуации, когда одна группа потоков вынуждена ждать другие и когда прописывать всякие объекты синхронизации и пользоваться ими необходимо. 1. Но нельзя ли просто пользоваться lock-free структурами/объектами и писать код, словно однопоточный? 2. Какие типы являются атомарными и потокобезопасными безо всяких std::atomic_что_то_там? 3. Верно ли утверждение, что lock-free код основывается лишь на атомарных типах и на встроенных свойствах работы с памятью и доступа к ней? 4. Какие именно свойства памяти помогают обеспечивать потокобезопасность? 5. Какие структуры в stl/boost потокобезопасны? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2015, 08:59 |
|
||
|
Объясните, зачем все эти пляски с многопоточностью, если можно использовать lock-free?
|
|||
|---|---|---|---|
|
#18+
>> 1. Но нельзя ли просто пользоваться lock-free структурами/объектами и писать код, словно однопоточный? Многопоточность нужно учитывать в любом случае. Хотя бы потому, что в C/C++ нужна явная декомпозиция процесса на потоки. Как я понял, lock-free это некое лукавство. Вместо mutex на входе в метод, он (метод) разбивается на множество фрагментов с синхронизацией на уровне некоторых потокобезопасных команд микропроцессора. Не факт, что любая аппаратная платформа покажет прибавку в производительности. Возможен даже обратный эффект. Из-за злоупотребления потокобезопасными командами МП и из-за сложности самого кода производительность может ухудшиться. >> 2. Какие типы являются атомарными и потокобезопасными безо всяких std::atomic_что_то_там? Зависит от библиотеки. Понятно, что Mutex. Вообще говоря для взаимодействия потоков используется не так много структур, поэтому делать потокобезопасными все типы нет смысла. Это негативно скажется на производительности и объеме кода. >> 3. Верно ли утверждение, что lock-free код основывается лишь на атомарных типах и на встроенных свойствах работы с памятью и доступа к ней? Лучше говорить об атомарных операциях. Одну и ту же память можно использовать по разному. >>4. Какие именно свойства памяти помогают обеспечивать потокобезопасность? Скорее это забота микропроцессора и/или арбитра шины доступа к памяти (и т.п. устройств, которые зависят от архитектуры ЭВМ). Эти устройства обеспечивают последовательный и атомарный доступ к памяти. Так команда Intel x86 XCHG, грубо говоря, блокирует шину, таким образом на время операции обеспечивая монопольный доступ к памяти - чтение ячейки памяти и запись в нее нового значения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2015, 13:04 |
|
||
|
Объясните, зачем все эти пляски с многопоточностью, если можно использовать lock-free?
|
|||
|---|---|---|---|
|
#18+
Забрел сюда из Java раздела. По моему опыту: - Нужно различать lock-free и wait-free. Первое - это оптимистичные блокировки, обычно на CAS. Они умеют определять ошибки синхронизации и перезапускают операцию. Время выполнения вторых не зависит от contention-а. - на высоком contention, lock-free алгоритмы могут работать хуже, чем блокирующая синхронизация. Оптимистичная блокировка основана на том, что обычно ошибки не происходит. Под большой нагрузкой это может быть не так - wait-free и тем более lock-free алгоритмы - очень сложны. Очень легко ошибиться и получить небезопасную программу. - вроде, в плюсах до сих пор нет memory model, независимой от конкретной платформы? Мьютексы хотя бы везде работают одинаково. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2015, 18:56 |
|
||
|
Объясните, зачем все эти пляски с многопоточностью, если можно использовать lock-free?
|
|||
|---|---|---|---|
|
#18+
log_hereКонечно, есть ситуации, когда одна группа потоков вынуждена ждать другие и когда прописывать всякие объекты синхронизации и пользоваться ими необходимо. 1. Но нельзя ли просто пользоваться lock-free структурами/объектами и писать код, словно однопоточный? Можно. Если они существуют или подходят под твои ограничения. log_here2. Какие типы являются атомарными и потокобезопасными безо всяких std::atomic_что_то_там? Безо всяких там -- никакие... log_here3. Верно ли утверждение, что lock-free код основывается лишь на атомарных типах и на встроенных свойствах работы с памятью и доступа к ней? Не знаю. log_here4. Какие именно свойства памяти помогают обеспечивать потокобезопасность? Так есть только одно свойство памяти, которое помогает её обеспечить -- TLS (thread local storage), все остальные -- мешают. log_here5. Какие структуры в stl/boost потокобезопасны? На сколько я помню, в STL -- никакие. В бусте -- может быть, какие-то есть. Буст большой... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2015, 19:08 |
|
||
|
Объясните, зачем все эти пляски с многопоточностью, если можно использовать lock-free?
|
|||
|---|---|---|---|
|
#18+
log_here1. Но нельзя ли просто пользоваться lock-free структурами/объектами и писать код, словно однопоточный?Можно конечно. Многопоточность нужна очень и очень редко на самом деле. log_here2. Какие типы являются атомарными и потокобезопасными безо всяких std::atomic_что_то_там?Нет потоко-безопасных типов. Вообще нет. Если только потоко-безопасные принципы работы. log_here3. Верно ли утверждение, что lock-free код основывается лишь на атомарных типах и на встроенных свойствах работы с памятью и доступа к ней?Нет. lock-free код основан на отсутствии lock'ов. log_here4. Какие именно свойства памяти помогают обеспечивать потокобезопасность?Никаких. Память не имеет таких свойств. log_here5. Какие структуры в stl/boost потокобезопасны?Опять таки: никакие. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2015, 19:13 |
|
||
|
Объясните, зачем все эти пляски с многопоточностью, если можно использовать lock-free?
|
|||
|---|---|---|---|
|
#18+
Как всё грустно. https://en.wikipedia.org/wiki/Memory_model_(programming) https://en.wikipedia.org/wiki/Memory_barrier Инструкции x86 MFENCE, LFENCE и SFENCE http://bartoszmilewski.com/2008/11/05/who-ordered-memory-fences-on-an-x86/ https://en.wikipedia.org/w/index.php?title=Lock-free_and_wait-free_algorithms&redirect=no И тяжелые наркотики: http://www.amazon.com/The-Multiprocessor-Programming-Revised-Reprint/dp/0123973376 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2015, 19:27 |
|
||
|
Объясните, зачем все эти пляски с многопоточностью, если можно использовать lock-free?
|
|||
|---|---|---|---|
|
#18+
Вкратце: в многоядерных процессорах перед каждым ядром есть кеш, так что если одно ядро записало значение в переменную, то другое может не увидеть это изменение неопределенное количество времени. Если переменная длиннее одного байта, то другой процессор может вообще увидеть только часть. Всё усугубляется тем, что некоторые процессоры могут переставлять инструкции местами, синхронизировать кеш кусками и делать много других прикольных вещей для ускорения работы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2015, 20:06 |
|
||
|
Объясните, зачем все эти пляски с многопоточностью, если можно использовать lock-free?
|
|||
|---|---|---|---|
|
#18+
scfВкратце: в многоядерных процессорах перед каждым ядром есть кеш, так что если одно ядро записало значение в переменную, то другое может не увидеть это изменение неопределенное количество времени. Если переменная длиннее одного байта, то другой процессор может вообще увидеть только часть. Всё усугубляется тем, что некоторые процессоры могут переставлять инструкции местами, синхронизировать кеш кусками и делать много других прикольных вещей для ускорения работы. Для синхронизации используется прямая запись минуя кэш ядра. В современных МП используется многоуровневое кэширование. Какие байты? Процессоры давно оперируют 64битными словами. Но чтение и запись памяти это разные операции. Между ними может вклинится другая операция чтения или записи, если процессор не предпринял специальных действий для монополизации доступа, если не ко всей памяти, то хотя бы к странице. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2015, 21:41 |
|
||
|
Объясните, зачем все эти пляски с многопоточностью, если можно использовать lock-free?
|
|||
|---|---|---|---|
|
#18+
Не совсем так категорично, некоторые типы на определенной архитектуре процессоров таки атомарные. Но практической стороны, ИМХО это применение не имеет, т.к толку от присвоения 1го слова например нет =) Есть редкие исключения и еще можно почитать про спинлоки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2015, 22:15 |
|
||
|
Объясните, зачем все эти пляски с многопоточностью, если можно использовать lock-free?
|
|||
|---|---|---|---|
|
#18+
mcureenabНо чтение и запись памяти это разные операции. Между ними может вклинится другая операция чтения или записи, не так всё страшно - у процессора есть инструкции типа LFENCE, SFENCE, MFENCE ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2015, 23:20 |
|
||
|
|

start [/forum/topic.php?fid=57&msg=39098275&tid=2018755]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
154ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
54ms |
get tp. blocked users: |
1ms |
| others: | 271ms |
| total: | 522ms |

| 0 / 0 |
