мимоходом, программистское

[avva]

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

Comments

[sleeping-death.livejournal.com]

а в чужом коде - особенно )

[iratus.livejournal.com]

Самые забавные гонки получаются, когда некоторые малообразованные программисты пишут многопоточный код без употребления volatile.

[squadette.livejournal.com]

ужасно
неужели у вас эту проблему еще не решили статическим анализом?

[rustler2000.livejournal.com]

Или static ))))

[netp-npokon.livejournal.com]

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

[iratus.livejournal.com]

Ну static еще туда сюда...
А вот без volatile результаты бывают интересные... и непредсказуемые...

[squadette.livejournal.com]

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

[netp-npokon.livejournal.com]

Нет, я не имею таких полномочий. Я сообщаю свою позицию, сформировавшуюся на основе некоторого опыта поиска гонок и участия в разработке соответствующих инструментов.

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

[msh.livejournal.com]

На самом деле, volatile часто бесполезно и обычно его использование - ошибка

http://www.mjmwired.net/kernel/Documentation/volatile-considered-harmful.txt

[vyhuhol.livejournal.com]

Во, как раз полез искать этот документ, когда прочитал.

[netp-npokon.livejournal.com]

Возможно, люди имеют в виду Java. Говорят, там volatile и правда имеет отношение к синхронизации.

[iratus.livejournal.com]

Это все совершенно правильно и что?
Использование volatile необходимо в тех случаях, когда DMA например или еще какие методы внешнего воздействия на состояние памяти.

В обычном программировании, можно обойтись, в embedded - часто невозможно.

[iratus.livejournal.com]

Люди имеют ввиду кернел, где действительно volatile большей частью лишний.

[msh.livejournal.com]

В известной статье Joel Spolsky писал, что "for some reason most people seem to be born without the part of the brain that understands pointers" - я обсуждал это как-то с коллегой, который по образованию EE, и он сказал, что точно так же многие не могут заниматься multithreaded programming, потому что не могут представлять программу в time domain. В лучше случае, они осваивают использование мьютексов как магических амулетов.

Спольский считает, что проблема - в использовании в обучении Java - раньше неспособные к поинтерам отсеивались прямо на первом курсе, когда начинали изучать C, а теперь могут дотянуть до диплома. Мой коллега говорил, что для выявления неспособных к multithreading хорошо помогает курс электроники.

Мне кажется, что в этом есть смысл.

Недавно на похожую тему писал panchul - http://panchul.livejournal.com/184647.html

[msh.livejournal.com]

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

[yigal_s]

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

This is because multi-threading is human-unfriendly approach to concurrency

[(Anonymous)]

This is because multi-threading is human-unfriendly approach to concurrency. Actor model, e.g., is much easier to reason about -- at least, actors are composable.

[itman.livejournal.com]

А я вот недавно воспользовался гуглёвым ThreadSanitizer и очень доволен результатом.