P>>>а в реальности что бывает P>>>a=5 P>>>b=10 S>>a > b=true
S>>Да, если a=5 b = 10 выполняется на одном процессоре, а сравнение на другом.
P>не-е-е-е, если вы намерено не запрограммировали и не выполнили сравнение в другом потоке или нити никогда не будет.
выше речь шла про процессор, и вообще-то такое возможно, если перед сравнением шедулер потоков ОС переключил выполнение потока на другой процессор.
Здравствуйте, Философ, Вы писали:
Ф>Здравствуйте, paradok, Вы писали:
MD>>>Само собой, что возможны случаи,
P>>пример кода чтобы можно было запустить и увидеть эти самые плавающие ошибки?
Ф>Можно. https://eric-lo.gitbook.io/lock-free-programming/memory-fence Ф>Там в статье пример кода, который это демонстрирует.
нет. там просто создаются две нити и их пускают обрабатывать одну и туже память.
речь же шла о коде без принудительного создания нитей
a=2
b=3 a>b=true
ЕМ>Здравствуйте, MadHuman, Вы писали:
MH>>такое возможно, если перед сравнением шедулер потоков ОС переключил выполнение потока на другой процессор.
ЕМ>Невозможно.
вы утверждаете что при вытесняющей многозадачности невозможно что шедулер ОС продолжит выполнение потока на другом ядре??
очевидно что такое возможно. планировщик по возможности старается конечно сохранить выполнение треда на одном ядре, но не всегда это возможно.
ЕМ>Если железо не обеспечивает синхронизации кэшей само, планировщик делает это при переключении.
планировщик при восстановлении потока, восстанавливает регистры, он не знает что делал поток и к какой памяти обращался.
хотя тут деталями не владею, возможно при перекидывании потока на другое ядро кроме восттановления регистров ОС и делает ещё что-то
чтоб обеспечить консистентность кэшей. а может это в железе как-то обеспечено.
Здравствуйте, MadHuman, Вы писали:
MH>вы утверждаете что при вытесняющей многозадачности невозможно что шедулер ОС продолжит выполнение потока на другом ядре??
Нет, конечно. Я утверждаю, что невозможны эффекты, которые Вы описывали.
MH>возможно при перекидывании потока на другое ядро кроме восттановления регистров ОС и делает ещё что-то чтоб обеспечить консистентность кэшей.
Не "возможно", а достоверно. Любая многопоточная ОС всегда гарантирует, что все данные отдельного потока, выполняемого на разных процессорах, будут выглядеть так же, как и на одном процессоре — если, конечно, поток специально не пытается отследить переключения. Проблемы могут возникать только при доступе к одним и тем же данным со стороны разных потоков.
ЕМ>Не "возможно", а достоверно. Любая многопоточная ОС всегда гарантирует, что все данные отдельного потока, выполняемого на разных процессорах, будут выглядеть так же, как и на одном процессоре
это да, без этого никак.
я выразил неуверенность, в том каким образом это достигается. как шедулер ОС может знать с какой памятью (ну кроме стэка) поток работал и как? никак.
поэтому вероятно это в железе обеспечено, но возможно ОС при продолжении работы потока на другом ядре даёт команду что-то типа — синхронизировать/сбросить кэши ядра (тот самый мемори барьер?).
Здравствуйте, MadHuman, Вы писали:
MH>как шедулер ОС может знать с какой памятью (ну кроме стэка) поток работал и как?
Ну вот как планировщик может знать, с какими регистрами поток работал, и с какими будет работать следующий? Может, какие-то регистры и не нужно сохранять, ибо их не испортят. Но, поскольку он этого не знает, то сохраняет все регистры — на всякий случай. Затратно, зато надежно. В служебных потоках виндового ядра, например, автоматически сохраняются только регистры общего назначения, а всякие FPU/SSE, с которыми в ядре работать не принято, надо сохранять и восстанавливать вручную.
MH>вероятно это в железе обеспечено, но возможно ОС при продолжении работы потока на другом ядре даёт команду что-то типа — синхронизировать/сбросить кэши ядра (тот самый мемори барьер?).
Сама по себе синхронизация кэшей в x86/x64 обеспечена аппаратно, так что планировщику достаточно лишь создать барьер, чтобы исключить перестановку операций. Ничего специального для этого делать не нужно, поскольку любому планировщику приходится использовать атомарные операции, каждая из которых в x86/x64 создает полный барьер.
Здравствуйте, Философ, Вы писали:
Ф>Это потому, что указанные инструкции используются для атомарных операций, при этом суть их — блокировки. Все приведённые инструкции неявно выставляют LOCK# на шину. Барьеры же используются для lock-free алгоритмов.
Дополню ответ Марти выше -- lock-free алгоритмы это суть алгоритмы на оснвое CAS, т.е. на основе атомарных инструкций процессора. Т.е. программист не использует никакие примитивы синхронизации и походы в ядро, вместо этого lock используеются на уровне железа. Т.е. lock-free на уровне железе нифига не lock-free, но судя
по всему, быстрее чем с примитивами синхронизации. Как-то так.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Однако определённый эффект на соседние ядра это тоже оказывает, поэтому, например, нельзя "бесплатно" (с точки зрения производительности) делать активную запись двумя потоками в две соседних ячейки памяти, если они попадают в одну кэш-линию. По каждому сигналу инвалидации кэш-линии, контроллер памяти будет ставить другое ядро на холд при попытке обращения к соседней ячейке, пока не синхронизирует два экземпляра этой кеш-линии. Хотя казалось бы, зачем тут синхронизация исполнения — ведь каждый поток пишет только в свою ячейку и никак не работает с соседней (гуглить false sharing).
А контроллер памяти что-то знает про L1\L2\L3, т.е. он ли решает, что какой-то процессор\ядро надо на холд
поставить? Мне казалось, это какая-то процессораная логика внутри цпу решает.
Здравствуйте, Sharov, Вы писали:
S>lock-free на уровне железе нифига не lock-free
Так не все ж алгоритмы, требующие атомарности и исключительности, подразумевают более долгое ожидание, чем требуется на банальную синхронизацию доступа к одной-двум ячейкам памяти. Даже обычный инкремент разделяемого счетчика традиционно было принято заворачивать в критическую секцию, которая традиционно же работала через примитивы синхронизации ОС, влекущие обращение к планировщику ядра. Замена на аппаратно атомарную операцию как раз и превращает действие в lock-free, подразумевая, что никто не тормозится дольше, чем это требуется на аппаратное выполнение команды в самом неудачном случае.
Кроме этого, многие lock-free алгоритмы не требуют, чтобы действие непременно выполнялось определенным потоком. В ряде случаев достаточно, чтобы его выполнил любой поток, который первым сумел получить доступ к ресурсу.
Ну а продвинутые lock-free алгоритмы еще и подразумевают сотрудничество между потоками. Если один выполнил команду типа test-and-set и получил нуль (ресурс был свободен), он выбирает одну последовательность действий, а другой, получив не нуль — другую. Задача в том, чтобы завершить операцию за некоторое разумное количество таких шагов, по времени заведомо выигрывающее у алгоритмов с ожиданием.
Здравствуйте, Sharov, Вы писали:
S>А контроллер памяти что-то знает про L1\L2\L3, т.е. он ли решает, что какой-то процессор\ядро надо на холд S>поставить? Мне казалось, это какая-то процессораная логика внутри цпу решает.
Думаю, в современных процах очень тяжело провести чёткую границу где заканчивается контроллер и начинается сам CPU, но для простоты картины да, можно считать контроллер отдельным модулем. Иначе как бы разные процессоры узнавали об изменениях в данных со стороны своих соседей? Речь не про многоядерность (там можно эту логику на тот же чип вкрячить), а про многопроцессорные конфигурации. Собственно, поэтому ранние двухпроцессорные сборки на Pentium и были бессмысленными для большинства применений — процессорам приходилось играть по максимально пессимистичному варианту синхронизации из-за неразвитой на тот момент механики согласования доступа к данным.
Здравствуйте, Mr.Delphist, Вы писали:
MD>можно считать контроллер отдельным модулем. Иначе как бы разные процессоры узнавали об изменениях в данных со стороны своих соседей?
Обмениваясь друг с другом по магистрали.
MD>ранние двухпроцессорные сборки на Pentium
Ранние были на 486. В нем и появилась команда cmpxchg.
MD>были бессмысленными для большинства применений
