Задачка для тех, кто думает что научился программировать

[вздымщик Цыпа]

Андрей АK в сообщении #160861 писал(а):

Так вот, если бы два ядра настолько одновременно выполняли бы код, то все механизмы синхронизации операционной системы перестали бы работать.

Андрей АK в сообщении #160861 писал(а):

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

Меня всегда забавляют применения дилетантского здравого смысла к вопросам, в которых без понятия. Эти Ваше утверждения звучат в точности так : «Земля плоская потому, что если бы это было не так, то все моря бы стекли вниз и люди со склонов тоже попадали. А уход кораблика за горизонт скорее всего объясняется искривлением световых лучей».

[Андрей АK]

вздымщик Цыпа писал(а):

Андрей АK в сообщении #160861 писал(а):

Так вот, если бы два ядра настолько одновременно выполняли бы код, то все механизмы синхронизации операционной системы перестали бы работать.

Андрей АK в сообщении #160861 писал(а):

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

Меня всегда забавляют применения дилетантского здравого смысла к вопросам, в которых без понятия. Эти Ваше утверждения звучат в точности так : «Земля плоская потому, что если бы это было не так, то все моря бы стекли вниз и люди со склонов тоже попадали. А уход кораблика за горизонт скорее всего объясняется искривлением световых лучей».

Если сказать нечего то лучше молчать, а такими постами вы свою бОльшую осведомлённость не показываете.
Если вы учавствовали в разработке механизмов синхронизации Windows , то поделитесь деталями реализации - как там два процессора не мешают друг другу находясь в одном пространстве?

[вздымщик Цыпа]

Андрей АK в сообщении #160881 писал(а):

Если вы учавствовали в разработке механизмов синхронизации Windows

К счастью нет. Последний виндовс, который я видал, был 3.11 для рабочих [и крестьянских] групп, там понятное дело, ни о каком SMP речи не было. И если мне повезет, то и никакого другого мне не придется разглядывать никада. Но это так, лирическое отступление.

Андрей АK в сообщении #160881 писал(а):

поделитесь деталями реализации - как там два процессора не мешают друг другу находясь в одном пространстве?

Да, так вот, про виндовс не скажу, а как оно в нормальной жизни устроено, Вы легко можете и сами прочитать здесь:
http://git.kernel.org/?p=linux/kernel/g ... git;a=tree
Так что, нет смысла пересказывать, если есть первоисточник

[worm2]

Андрей АK,
Потоки выполнения (threads) одного процесса всегда работают в адресном пространстве этого процесса. По определению (не зависящему от конкретной аппаратуры или ОС). Иначе это были бы уже не потоки выполнения, а процессы.
При этом в многопроцессорной системе потоки одного процесса, разумеется, могут выполняться на разных процессорах (ядрах), физически одновременно.
И хотя в некоторых архитектурах возможно автоматическое (программное либо аппаратное) разграничение доступа, в мейнстриме ничего подобного нет (если не считать таких низкоуровневых средств, как, наприемер, разрешение конфликтов при обращении к контроллеру памяти и обеспечение атомарности доступа к данным, да и это не всегда есть), и весь арбитраж ложится на плечи программиста (ОС лишь предоставляет средства для него, не более того).

[Андрей АK]

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

Цитата:

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

Т.е. если произошло нарушение очерёдности обращения к памяти (поздний трэд обратился к памяти, которую обрабатывает ранний тред) - то произойдёт откат трэда и данные пересчитают.

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

[вздымщик Цыпа]

Андрей АK в сообщении #160910 писал(а):

Но может быть это не наш случай

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

[Фома]

Андрей АK писал(а):

Ладно, пришлось самому поискать детали.

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

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

[Андрей АK]

По английски мне тяжело разобрать детали.
А непонятно то , что не сказано - при каких условиях может наступить этот случай - раз так, то это вполне может оказаться обычное недопонимание - кто-то где-то прочтал что операции могут выполняться не в том порядке - начал фантазировать: "а что будет если ..." а на самом деле может всё будет считаться не так.
Я же никогда не доверяю выводам сделанным из неполных данных и общих предпосылок.
Под фразой "изменён порядок вычисления" - может всё что угодно подразумеваться.

[Pavia]

Согласен. В статье написано что может. Но ненаписанное когда. Я тут привел выдержки для Intel x86-64. Как видно то, что написано в статье не соответствует действительности. Дело в том, что там написано, что такое может быть, но незаписано когда.

Давайте рассуждать здраво. Допустим нам надо прочитать данные из ячейки a и записать в b получается нам нужна синхронизация даже на простом случаи. Ведь написано что считывание может меняться с записью. Поэтому ясно, что так происходить не должно и не происходит. Как это объесняет статья? Да команды могут поменяться, но только при определенных условиях, а в статье это не раскрыто.

[Фома]

Для всех кому интересны проблемы multithreading'а, я выложил download ссылку на книгу The art of multiprocessor programming.

[Фома]

Вчера разговаривал по телефону со своим старым другом, который вот уже 15 лет живет и работает в США. Рассказал ему о споре в этой ветке форума. Он в ответ рассказа мне историю, которая произошла в одном из крупнейших американских банков несколько лет тому назад. Эта история напрямую не связана с перестановкой команд, но имеет прямое отношение к подводным камням многопоточности.
Итак, группа программистов реализовывала на Java серверное приложение, которое запускало внутри себя несколько потоков. В основном потоке была объявлена переменная (например int counter = 0).
Каждый порожденный поток при запуске вызывал функцию синхронизированного инкремента переменной counter на 1, а при окончании работы аналогичную функцию декремента на 1. При этом основной поток зависал примерно в таком цикле ожидания:

while(counter > 0)
{

    // Делаем что-то и ждем пока завершатся все порожденные потоки

}

Ребята совершенно справедливо решили, что для изменения значения счетчика необходимо писать функции синхронизированного инкремента(декремента) в порожденных потоках. Но в основном потоке, подумали они, раз всего лишь читается значение переменной счетчика, то ни о чем беспокоится не надо, все будет - OK. Так вот это приложение подвисало 2-3 раза в день. Боролись с этим месяц, пока им не подсказали объявить counter, как volatile.

А причина проста - кеширование значения счетчика перед выполнением цикла в основном потоке. Например, JIT компилятор Java, мог запросто помещать значение counter в регистр, видя что его значение внутри цикла не изменяется, но часто читается.

[вздымщик Цыпа]

Фома в сообщении #161501 писал(а):

Например, JIT компилятор Java, мог запросто помещать значение counter в регистр, видя что его значение внутри цикла не изменяется, но часто читается.

Что на самом деле довольно забавно. Ведь если в «Делаем что-то и ждем пока завершатся все порожденные потоки» есть хотя бы один вызов функции, содержание которой компайлеру неизвестно, он просто обязан перезачесть counter из памяти, поскольку он мог быть модифицирован там. Это говорит о том, что либо в цикле делалась какая-то глупость типа пустого цикла жрущего CPU, либо компайлер Java предоставляет «медвежьи услуги» по рискованной оптимизации.

[Фома]

вздымщик Цыпа писал(а):

либо компайлер Java предоставляет «медвежьи услуги» по рискованной оптимизации.

Где-то я слышал, что в версиях Java до 5 были какие-то шероховатости с многопоточностью.

Но, в любом случае, лучше пере..., чем недо...

[вздымщик Цыпа]

Фома в сообщении #161525 писал(а):

Но, в любом случае, лучше пере..., чем недо...

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

[Фома]

вздымщик Цыпа писал(а):

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

В Java прямой аналог глобальных переменных - статические переменные класса. Но в данном случае, в качестве counter могла выступать вполне рядовая (экземплярная) переменная класса.