о синхронизации

[avva]

Странное дело - по опыту интервьюирования в последнее время, кандидаты почти всегда хорошо знают, что такое мьютексы, семафоры и критические секции, зачем они нужны и какие есть основные предосторожности в работе с ними; но мало кто почти никто не знает, что бывает atomic increment (и другие атомарные операции) и как ими пользоваться. Я почему-то думал, что это знание примерно одного уровня и источника.

(точнее, фразу atomic increment знают, но думают, например, что это работает "через мьютексы" или "с помощью OS")

Comments

[longobard.livejournal.com]

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

[djuffin.livejournal.com]

А как реализовать "обычный мьютекс" без использования атомарных операций?

[a-konst.livejournal.com]

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

[8f4a4bdd981a.livejournal.com]

Зависит от моды собеседователей, кандидаты просто учат типовые вопросы.

[cema.livejournal.com]

+1

[krocodl.livejournal.com]

потому что до cas доходят уже тогда, когда вдоволь наелись грабель с блокирующими подходами. А с ними у большинства знакомство крайне поверхностное или теоретическое

[getman.livejournal.com]

Это же разные уровни, сначала на курсе алгоритмов запугивают критическими секциями, потом на курсе ассемблера студенты боятся даже думать об атомарный операциях( а вдруг не сработает?).

[archaicos.livejournal.com]

Они и про CAS наверное не знают. :)

Ещё часто не знают кто делает проверку доступа в память по заданному адресу. Часто говорят, что ОС, не особо задумываясь. Знатная бы была производительность у компа, если бы на каждой инструкции каждой программы ОС бы проверяла адрес и права доступа. Access Violation, как он известен в простонародьи, - это такая магия в ОС. :)

[a-konst.livejournal.com]

Простите, а какой CAS вы имеете ввиду?

[b0rg.livejournal.com]

на каждом втором интервью теперь спрашивают про мутексы. А потом сажают фтп файло качать через SQL Server Integration Services. На вижуал васике ага.

[a-konst.livejournal.com]

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

[furry.livejournal.com]

О. А я вот как-то стесняюсь изливать душу по поводу проведенных интервью. Ну вроде как разглашу военную тайну, что я такое спрашиваю ;)

[avva.livejournal.com]

Я тоже избегаю этого, просто подумал, что один простой частный пример ничему не навредит.

[mikkim08.livejournal.com]

А conditional variables (posix threads) они знают ?

[avva.livejournal.com]

Не знаю, смотря кто, думаю. Я не задавал вопросов, которые их требуют.

[iratus.livejournal.com]

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

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

[netp-npokon.livejournal.com]

почему правильно написанный код совсем не обязательно должен требовать мьютексной синхронизации, например.
Это какое-то чересчур общее утверждение. Если речь не идет об однопоточном коде и/или отсутствии разделяемых данных, то корректно написанному коду придется как-то синхронизоваться, как ни крути.
Или правильно написанный код - это тот, в котором каждый поток работает со своей копией данных?

[ircicq.livejournal.com]

Наверное это коррелирует со знанием ассемблера.

Из знания системных примитивов логически никак не следует, что некоторые частные случаи реализуемы аппаратно.

[yigal_s]

кстати, абсолютно верно.

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

Практически единственный общедоступный источник информации об их устройстве - знание ассемблера.

[gineer.livejournal.com]

подстраиваются под то о чем спрашивают. :))

Гуси и их свиньи...

[greps.livejournal.com]

ИМХО это сакральное знание было Вами благоприобретено после того как Вас приняли на конкретную работу требующую повышения знаний этого типа, а не до того. ("Вами" конечно собирательный образ, а не конкретный интервьюер)
Отсюда вывод - проверка такого рода знаний так же бессмысленна (да и несправедлива по отношению к Вашему будущему сотруднику) как и задания вопросов типа "А ты знаешь что я знаю но не скажу?", загадок типа "как релизовать бинарный поиск без операции сравнения" и "догадайся что cкажет компайлер HPUX если бросить эксепшн из дестрактора". То есть это - да, работает как фильтр - кого берем кого не берем, но с тем же успехом можно использовать рост или цвет глаз кандидата. ИМХО - цвет глаз честнее...

[iratus.livejournal.com]

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

[msh.livejournal.com]

Потому что программированию сейчас учат начиная с Java, а там mutex - это синтаксис языка, а atomic variables - довольно малоизвестная библиотека, которая еще и не сразу появилась и не во все книги вошла.

[kmmbvnr.livejournal.com]

во-во тоже такая мысль в голову пришла )

[gul-kiev.livejournal.com]

Я, вот, живой пример (хоть и не программист). Про критические секции и мьютексы знаю, а про атомарные инструкции - нет.
Ну, то есть, в принципе знаю, что команда процессора выполняется атомарно, что можно инкрементировать переменную или поменять местами содержимое регистров одной командой на некоторых процессорах (в частности, на x86), но вот что будет, если моё "i++" будет выполняться на неведомой архитектуре с несколькими неизвестными мне процессорами, да ещё и будучи скомпилирована неизвестным мне компилятором, либо если i окажется 64-битным на 32-битной архитектуре - не знаю. Полагаю, что ничего хорошего, и ловить race condition можно будет долго. А потому лучше обвешу мьютексами от греха.
Наверное, в каких-то случаях есть какие-нибудь специальные слова для гарантии атомарности, но это частности, работающие в какой-нибудь одной среде и на одной платформе, а мьютексы - это общее, теоретическое, различается только реализация.
Примерно как можно знать области видимости и правила наследования, но не знать конкретную pragma конкретного компилятора, которая в каких-то случаях позволяет сделать более эффективный код. Можно знать, что в обработчике сигнала ничего лишнего делать не нужно, но не знать, что в большинстве современных систем оттуда менять глобальные переменные безопасно.
Это, кажется, немного разные уровни знаний - теоретический и практический.

[avva.livejournal.com]

В 99% случаев лучше не морочить себе голову атомарными инструкциями, и обвешивать, где надо, мьютексами.

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

Я, кроме того, хочу добавить - кажется, многие люди решили, будто я считаю, что кандидат обязан знать об атомарных операциях. Это не так. Если кандидат хорошо это знает и умеет пользоваться, это небольшой плюс в его пользу; если нет - это в худшем случае слабый сигнал, да и то вряд ли. Знать и уметь пользоваться мьютексами с моей точки зрения в 100 раз важнее. Просто меня удивило, что человек за человеком не знают о них - мне казалось, что это знание я приобрел примерно в то же время, когда узнал о семафорах и мьютексах, и что это типично. Наверное, это не так.

[semen-petr.livejournal.com]

А разницу между spinlock и blocking lock, напримери мьютекс, знают? По-моему, если кандидату итался не совсем уж паршивый курс ОС, то это он должен знать.

[asox.livejournal.com]

Никогда не думал, что команду INC и DEC можно обозвать такими мудрёными словесами.

[migmit.livejournal.com]

Они не атомарные (сами по себе).

[migmit.livejournal.com]

Я тоже думал, что это примерно на одной ступеньке. Странно.

[auto194419.livejournal.com]

просто они в детстве не читали System Design with ADA (Prentice-Hall software series) by
R.J.A. Buhr :)

[norian.livejournal.com]

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

самый частый случай - чтобы треды не передрались за объект или подождали пока придёт запрос от клиента

[pesec.livejournal.com]

Следующим шагом за atomic increment обычно бывает вопрос, почему массив atomic counter-ов (без padding-а) - очень плохая идея.

[oblomov-jerusal.livejournal.com]

Упоминание padding-а позволяет угадать ответ. (Аппаратная реализация может быть неэффективной/неработающей при плохом alignment, правильно?)

[oblomov-jerusal.livejournal.com]

Это, типа, предварительное собеседование?

[kmmbvnr.livejournal.com]

А язык какой?

В java atomic операции с стандартной библиотеке появились сильно позже. Соответственно не в каждой книжке про них написано.

[blacklion.livejournal.com]

А при чём тут язык? Мы программирование обсуждаем или использование конкретного языка?

[zlaya-rifma.livejournal.com]

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