mem inc r1
3: mov mem r1
итого 3 операции!!! давай рассмотрим варианты:
1 ядро, 1 Писатель, N читателей - все гуд!
1 ядро, N Писателей, N читателей - все гуд если у нас кооперативная ОСь и мы сами контралируем переключение контекста!!
Все ПЛОХО если вытесняющая ОСь, нас могут прервать перед 2-ой строчкой (см выше и скажем что в переменной нолик) и выполнить операцию записи в другом потоке потом вернуться в прерванный поток что? правильно записи 2 а в переменной 1-чка (фэйл) мы сломали логику (Гонка данных) Спасет атомик (его прервать ОСь не сможет, не позволит АЛУ) в случае эксклюзивных атомиков таких как в ARM (ldrEX strEX) нас прервут, но скажут что операция не выполнена при повтороном включении потока (атомик функция тупо повторит операцию!).
2 ядра, 1 Писатель, N чит. - все плохо не с чтением а с записью - гонка данных между потоками. у нас нет гарантий четкой очередности. нужен атомик! (если такая ситуация не возможна скажем писатель закреплен за одним ядром то все хорошо!) Если у нас контролируемая кооперативность то тоже все гуд, даже атомик не нужен!
2 ядра, N Писателей, N чит. - все плохо опять гонка данных. у нас нет гарантий четкой очередности. Если у нас нет контролируемой кооперативности! нужен атомик! (Если опять контролируем ядро и потоки писателей выполняются четко и последовательно все айс)
PS. в случае N ядер то необходим барьер, чтобы синхронизировать кэши первого уровня (они у каждого ядра свои(в современных ЦПУ)). просто можем записать значение, а читатели его тупо не видят, этих данных в их кэше еще нет! Атомик не содержит в себе барьера!!
Примитив синхронизации - это Атомик + барьер.
PS2. При вытесняющей многозадачности ставят барьер в конце переключения контекста, по крайней мере в Linux и для ARM архитектуры.
ну, вот я про случай 2 ядра, 1 писатель, n читателей. И запись за ядром.
Обсуждают сегодня