Мне кажется, вы сейчас лукавите — оформляете свое недовольство в социально-пристойную форму чтобы придать ему бОльшую легитимность. Новость «Бомжи в Нью-Йорке используют QR-коды для привлечения пожертвований» вполне себе вписывается в тематику хабра — ну не то, чтобы сильно круто, но как-никак «ИТ и общество». Сочли бы вы такую статью подменой целей, пиаром бомжевания, и так далее?
> Я не против поведения автора, я против его пропаганды данного способа жизни, который многим может навредить, понимаете?
Кто конкретно эти люди, за которых вы так беспокоитесь? Назовите их имена, расскажите, почему они вам так важны? Вы им папа или мама? Почему вы отбираете у них право отвечать за свою собственную жизнь, за свой выбор, за свои воздушные замки? Вы полагаете, что вы лучше кого-то знаете, как этому кому-то жить, в какие фантазии верить? Вот смотрите — вы для себя решили, что вам такие фантазии не подходят — вы предпочитаете верить в другие фантазии. Ок, это ваш выбор. Но если у вас есть ваш выбор — то у других есть их выбор, а? Кто сказал вам, что ваш выбор — это не воздушный замок? Кто сказал вам, что профессия и семья — это не подмена целей?
Вот и получается что вот это «Право выбора, личная ответственность — это всё ок. Я за двумя руками. » — это просто слова. Вы же в них не верите
Мне кажется, уж простите, вы все-таки мало думали. Разве вам не приходило в голову, что все люди — даже с профессиями и семьями — не будут жить вечно? Разве профессия и семья — гарантия от смерти? Даже от внезапной и нелепой смерти? Или профессионалы с семьями не умирают от поножовщины?
Разве вам не приходило в голову, что вы предпочитаете видеть вокруг людей с профессиями и семьями просто потому, что их существование придает вам больше уверенности в вашем собственном выборе — в котором вы сами, наедине с собой, не так уж уверены (вы же тоже завидовали Валентину, а)?
>Я вообще признаю право каждого жить как-угодно, но что сей молодёжный вызов и бунт против правил делает на главной Хабра?
Я замечаю, как вы пытаетесь обесценить то, что сделал автор, выставляя его этаким пацанчиком-бунтарем. Да, тематика не очень айтишная, я согласен. Но на главную, как я понял, пост вывел не автор, а читатели. Мне кажется, это и есть оценка — нужен ли здесь такой пост, разве нет?
Лично мне очень поучительно наблюдать за тем, насколько даже умные люди становятся глухими и слепыми, когда подвергнуты сомнению их фундаментальные убеждения о том, как устроен мир, и как правильно в нем жить. Поучительно — может звучать несколько отстраненно, но я и очень хорошо на своем опыте знаю, насколько болезненно сталкиваться с тем фактом, что никакого правильного способа жить — не существует. Существуют законы природы, все, что сверх — лишь мой личный выбор и моя ответственность за него. И никто и никогда не сможет мне сказать, сколько жизней я мог бы прожить, но не прожил.
Вы, наверное, очень хорошо знаете в чем универсальный, для всех подходящий смысл жизни. Раз так легко можете судить, какая жизнь загубленная, а какая не загубленная. Вы никогда не думали, например, что, возможно, это вы, со своими профессиями и семьями, загубили свою жизнь — а Валентин-то как раз свою прожил? ;)
Я вот, кстати, такого же мнения — нормальных специалистов днем с огнем не сыщешь, когда такой появляется — это праздник просто. И все это знают — и наниматели, и сами специалисты. И зачем этому специалисту тратить время и силы и деньги на прохождение сертификации, которая к его опыту ничего не добавит, и на которую никто все равно не смотрит? Вот и получается ситуация, что человек с сертификатами уже скорее подозрение вызывает :)
Удивлен этим — за 11 лет карьеры не помню ни одного раза, чтобы сертификат по яве зачитывался хоть сколь-либо существенно сам по себе. Может, озвучите названия крупных компаний? Любопытно просто, что это за компания, которая, скажем, разработчику с опытом даст/не даст бонус только на основании сертификата.
«Я пришел устраиваться на эксперта» вообще-то. Умение реалистично оценивать свои навыки, и их границы — это даже не про эксперта, это просто про хорошего специалиста.
>Я не знаток модели памяти явы, слышал только, что в ней применяется модель sequential consistency, и существует довольно обширное её описание.
Да, канонически в яве все synchronization actions действительно имеют SC-семантику. Модель сама по себе не такая уж обширная. Обширное описание, скорее, есть у причин почему она такая, какая есть, и как к этому пришли — с этой точки зрения, уверен, описание модели C++ будет только еще более обширным. Но есть такая тонкость, что в яве нет undefined behavior по изначальному дизайну языка. Потому примерно половина объема (и 3/4 сложности) модели памяти в яве это именно попытка задать, пусть очень сложную, но все-таки определенную семантику даже коду с гонками. Попытка эта, в общем-то, провалилась — через пару лет после публикации и реализации в этой части были обнаружены баги, которые не позволяли реализовывать важные оптимизации, поэтому существующие реализации JVM фактически нарушают спецификацию где-то в темных углах кода с data race. Есть несколько предложений, как исправить ошибки, но все они не совместимы с текущей версией JMM, поэтому пока все просто закрывают на это глаза. Как я понимаю, этот фэйл является одной из причин почему сейчас гуру concurrency (Ханс Боэм, Даг Ли, и прочие) в один голос повторяют «data race is evil».
Если не брать эту темную сторону, то оригинальная JMM ни разу не сложнее CMM, даже проще — потому что есть только два варианта memory_ordering: relaxed/SC, причем используемый вариант привязан к типу переменной изначально, а не к конкретной операции доступа: есть volatile переменные, все операции с которыми всегда SC, и есть обычные переменные, которые всегда relaxed. Это, собственно, второй ее недостаток — очевидно, что SC несовместимо со scalability, без введения чего-то типа acquire/release/consume нереально линейно масштабироваться дальше пары десятков процессоров. Фактически же, аналоги acquire/release/consume операций уже некоторое время имеются в яве, но это полулегальные операции, потому что официального апдейта JMM с их формализацией нет и не предвидится.
>Мыслить в терминах отношений happens-before и пр. у меня как-то не особо получается.
Ну, среди явистов тоже очень многие рассуждают в терминах барьеров. Как эвристические рассуждения это неплохо, но суть в том, что если вы попытаетесь сделать рассуждения про барьеры и возможные перестановки более строгим — вы, собственно, и получите happens-before notation. Так что лучше уж, как мне кажется, идти сюда сразу же, как вы поймали общую идею алгоритма, и начинаете думать про реализацию.
> В нашем частном случае формальная модель — это happeds-before, synchronized-with и пр. отношения, а интерпретация — в конечном счете, банальные барьеры.
Я думаю, что здесь вы как раз ошибаетесь. Процессоры не господом богом с неба спущены — они разрабатываются инженерами под нужды разработчиков. Я где-то читал, что при разработке JMM были случаи, когда разработчики Intel подправляли спецификацию своих процессоров по итогам обсуждения — и это вполне логично, ибо кому нужны процессоры с набором команд, с которыми неудобно и ненадежно программировать? Судьба пресловутой Alpha очень наглядна в этом смысле. Разумеется, это двусторонний диалог, но это именно диалог — в отличие от законов природы, с которыми особо-то не подискутируешь.
Например, абсолютное большинство современных general purposes процессоров создает иллюзию SC в однопоточном случае — хотя реально они все суперскалярные и используют внеочередное исполнение команд — то есть поддержание иллюзии SC-исполнения на самом деле стоит немалого гемороя их инженерам. Зачем они идут на этот геморой? — Потому что у процессора с менее тривиальной моделью исполнения будут большие проблемы с продажами. Наглядный пример того, как именно процессоры делаются под концепцию, а не наоборот.
… Вообще, у меня есть мнение, что дело здесь не в сложности именно HB, а в том, что программисты сейчас вообще отвыкли серьезно относиться к надежности своего кода. К тому, что корректность алгоритма нужно доказывать, а не «жопой чуять». Если вы когда-нибудь пробовали доказывать корректность однопоточных алгоритмов, вы должны бы заметить, что разница в сложности не такая уж большая. Но для однопоточного кода отладка и тестирование довольно дешевы, дешевле, чем формальное доказательство — уже целое поколение (я в их числе) выросло на идеологии «достаточное количество юнит-тестов является доказательством корректности программы». И когда оказывается, что для многопоточного случая все это на порядки менее эффективно, и мы снова сталкиваемся с необходимостью формального доказательства — вот тут-то и возникает ощущение огромной сложности.
В частности, лично мне кажется, что основной фокус при создании конкурентных алгоритмов должен быть не на том, как избежать возни с формальным доказательством, а на том, как а) избежать многопоточности вообще б) если уж удалось — сделать алгоритм настолько простым, чтобы ошибиться было просто негде. Потому что сколько либо сложный конкурентный алгоритм требует столько внимательности, проверок и перепроверок для своего написания, что это определенно не работа для одного человека. Тут нужно несколько очень опытных специалистов для постоянного ревью, и месяцы тестирования. Это слишком дорого для личных целей, это оправдано либо в качестве обучения, либо в составе очень популярных фреймворков, вокруг которых сильное коммьюнити.
>По сути, обращение к атомарной переменной — это всегда data race; можно сказать, что это легализованный стандартом data race, все остальные — UB
На мой взгляд, data race — это само по себе и есть соглашение. Соглашение о том, какие конкурирующие инструкции работы с памятью мы считаем легальными, а какие ведут к потенциально нехорошему поведению. Т.е. data race — это и есть название для тех паттернов конкурирующего доступа к памяти, которые порождают что-то нехорошее. А обычное определение «запись и чтение/запись из разных потоков, не упорядоченное SA» — просто показывает, какие конфликты можно разрулить на уровне процессора/контролера памяти/компилятора, а какие конфликты требуют участия программиста, потому что эффективно их разрулить автоматически пока невозможно.
>Барьер я могу пощупать, он материален, он воплощается в инструкции процессора. Об отношениях пусть говорят люди более сведущие, например, А.Вильямс.
Я думаю, это просто С-шный бэкграунд сказывается. В яве к happens-before уже привыкли. И это большой вопрос, на самом деле, что первично — нотация happens-before восходит еще к статье Лампорта из 70-х, когда еще писали в терминах явных сообщений между узлами, а не в терминах shared memory.
Если честно, мне как раз не очень понятно, как вы целостно рассуждаете о корректности алгоритма в терминах барьеров? Да еще и кроссплатформенно — т.е. когда вы не можете явно описать, как именно реализован этот барьер на этой архитектуре, что за конкретные действия за ним стоят. На мой взгляд, нотация относительного порядка (aka happens-before) единственный достаточно универсальный способ рассуждать о взаимодействии потоков, это как раз семантика барьеров должна описываться в терминах happens-before. Правда, я не вдавался особо в глубины C++ MM, но я помню дискуссии в concurrency-interest, где Ханс Боэм писал, что явные барьеры в C-MM оставлены в основном для обратной совместимости, чтобы не нужно было переписывать уже существующие алгоритмы с 0. Но вообще, как я понял, он считает их рудиментом, и довольно опасным рудиментом — с той точки зрения, что с ними сложнее писать корректный кроссплатформенный код.
>Применение более слабых моделей – acquire/release или relaxed – требует верификации алгоритма.
Тут очень двусмысленно звучит — как будто, если вы используете SC-модель доступа к атомикам, то верификация вообще не нужна. Даже если мы говорим только про отсутствие data race (а не про race conditions) — SC-семантика гарантирует вам data race free только и именно для тех переменных, к которым вы обращаетесь через SC-примитивы. Для всех остальных переменных ничего априори не гарантируется, все гарантии необходимо выводить через те самые happens-before, за которыми вы послали так далеко :). А ведь ни одна разумная программа не состоит только из атомиков, так что даже используя только SC-атомики можно легко и непринужденно получить код с гонками за счет «обычных» переменных, которые не несут явной спецификации memory-order. Мне кажется, это ваше утверждение стоит уточнить, во избежание
Вот когда тебе такого типа вопрос на собеседовании задают — не знаешь, как реагировать. А вот когда ты сам в роли собеседующего, и видишь кандидата с высшим техническим, с неплохим резюме, который сидит перед тобой, и уже третью минуту не может посчитать 2500 * 200 (я не специально арифметику спрашивал, просто нужно было что-то оценить по ходу решения задачи), причем он уже выдал два варианта, которые даже по порядку не сходились — тут тоже не знаешь, как реагировать. Правда, очень неловко было — я совершенно не представлял, как человеку здесь можно помочь, потому что не представлял, в чем здесь может быть затык вообще. Ну не учить же мне выпускника технического вуза счету в уме?
Отсюда и растут ноги всяких странных вопросов — повидаешь несколько таких случаев, и начинаешь на молоко дуть.
Володя, опомнись — хватит уже все секреты-то выдавать! И так ты уже половину наших секретных техник всем раструбил — как теперь жажду власти удовлетворятьсобеседовать-то?
Ну вообще-то в большинстве крупных компаний официально именно такие ценности и провозглашаются. Другое дело, что для российских компаний (я бы сказал — для составляющих их людей) такого рода ценности — это, пока что, не выстраданная ими самими реальность, а купленная у западных коучей модная тряпка, про которую толком никто не понимает, за что там вообще деньги-то заплачены, и что именно в ней такого хорошего, кроме того, что модно.
Прежде чем согласиться с результатом, полученным по этой формуле, неплохо бы понять, откуда вы вообще эту формулу взяли, какая модель эффективности за ней стоит, и какова статистическая значимость ее экспериментальных подтверждений. А так же пару-тройку альтернативных моделей, с их экспериментальными подтверждениями.
Например, по моему опыту в команде достаточно одного-двух человек с хорошими коммуникативными талантами — они легко компенсируют традиционный недостаток таких талантов у остальных. Причем эту роль вполне может занимать «играющий менеджер»
«По душам» может быть беседа на любую тему. Именно поэтому мне странно слышать, что «10 скользких мест С++» вам как тема для беседы по душам не подходит — где же ваш эмоциональный интеллект? :-Р
Я, между прочим, серьезно: мой опыт показывает, что совершенно не важно о чем спрашивать, если копать достаточно глубоко, и слушать достаточно внимательно. «Когда человек входит в комнату — вместе с ним входит вся его жизнь» (с) Можно хоть о политической ситуации в стране говорить — и на примере этого понять, умеет ли человек вообще мыслить, в каких масштабах он способен мыслить, сколько влияющих факторов он способен учитывать в своих ментальных моделях, насколько он склонен подгонять модель под желаемый ответ, и так далее. В этом, как мне кажется, и был исходный смысл гугловских головоломок — который сейчас уже потерян из-за их заезженности, и гугл прав, что от них отказался — но идея-то по прежнему работает.
Единственная проблема возникает если человек вообще на эту тему не хочет говорить — поэтому технические вопросы спрашивать, в среднем по больнице, удобнее — к ним кандидат более-менее готов, и обычно заливается соловьем.
Я не знаю С++ головоломок, но в свое время я очень любил расспрашивать про контракт .equals() в яве (сейчас это уже не актуально, потому что многие тупо выучили) — потому что с небольшими подсказками можно догадаться, и на одном маленьком примере проявляются сразу несколько важных вещей про инженерное дело. Мне было важно видеть реакцию человека.
А в остальном — тонкость в том, что у каждого свой способ ведения интервью, который ему, очевидно, подходит, т.е. позволяет нанимать нужных людей. И это понятно: свести к минимуму процент ложно-положительных исходов можно просто перебирая разные фильтры один за одним, за счет долгого опыта. Гораздо интереснее было бы задаться комплиментарным вопросом: какой у конкретного способа процент ложно-отрицательных результатов? Сколько подходящих людей конкретный способ отсеивает? Еще одна интересная метрика качества: насколько способ воспроизводим? Можете ли вы объяснить свой метод новому коллеге, и быть уверенным, что он будет набирать плюс-минус тех же людей, что и вы?
Мне кажется, что сравнивать методы имеет смысл как раз по этим характеристикам — потому что с точки зрения бизнеса они могут оказаться гораздо важнее.
У разных людей в интервью разные фокусы — это очевидно зависит от целей и контекста. Важно только понимать, что нет правильного/неправильного фокуса — есть подходящий/не подходящий лично вам (как человеку — ведущему интервью), вашей конкретной компании (т.е. пропускающий кандидатов эффективных с точки зрения вложения в них денег), этому кандидату (с точки зрения того, может/не может он такое интервью пройти, и насколько оно ему будет комфортно ощущаться).
Фокусироваться на мотивации в ущерб навыкам — это, безусловно, интересная стратегия. Я вижу ее плюсы лично для меня как будущего коллеги — с мотивированными, «горящими» людьми работать приятно (и весело). Но я так же вижу ее и недостатки: далеко не все технические навыки могут быть изучены за разумный период времени. Например: изучить новый язык программирования можно за месяц. Но научиться свободно им пользоваться, интуитивно и лаконично переводя свои ментальные модели сразу в его синтаксические конструкции — нужно несколько лет минимум (и определенный склад ума — некоторые люди и на родном русском-то не могут научиться ясно выражать свои мысли). Как нанимать «за энтузиазм» человека, который не имеет этих нескольких лет опыта? Какая вероятность, что внутренне-мотивированный сотрудник продержится в компании несколько лет, прежде чем его компетенция, наконец, достигнет нужного уровня?
На мой взгляд, ориентироваться на энтузиазм тем эффективнее, чем меньший порог вхождения в вашу область работы. Скажем, на рынке есть 20% сотрудников, которые подходят вам по навыкам, и 10% подходящих по уровню мотивированности и активности жизненной позиции — очевидно, эффективнее фильтровать по жизненной позиции. А если вам подходят 5% сотрудников по навыкам, и те же 10% по горючести — эффективнее отбирать по навыкам. Простейший принцип «сначала фильтруем по признаку с наивысшей селективностью»
Что-то подобное делает JVM автоматически, если размер кучи на 64-битной системе меньше некого предела. До 4Гб большинство указателей будут прозрачно 32-битными указатели, до 32Гб — с offset-ом (где можно, конечно — иногда придется их разворачивать в полные)
Уходите вы уже с ваших C++ — у нас, на яве, такие печеньки для concurrency… :)
В языках с GC в первом приближении ABA нет — и это их огромнейшее достоинство в области lock-free.
Но, конечно, если вы начинаете делать свой собственный memory-management, скажем, заводите пул объектов, чтобы снять нагрузку на GC — вы можете получить ABA назад. Нужно быть очень аккуратным, когда делаете одновременно lock-free и GC-less компоненты.
> Я не против поведения автора, я против его пропаганды данного способа жизни, который многим может навредить, понимаете?
Кто конкретно эти люди, за которых вы так беспокоитесь? Назовите их имена, расскажите, почему они вам так важны? Вы им папа или мама? Почему вы отбираете у них право отвечать за свою собственную жизнь, за свой выбор, за свои воздушные замки? Вы полагаете, что вы лучше кого-то знаете, как этому кому-то жить, в какие фантазии верить? Вот смотрите — вы для себя решили, что вам такие фантазии не подходят — вы предпочитаете верить в другие фантазии. Ок, это ваш выбор. Но если у вас есть ваш выбор — то у других есть их выбор, а? Кто сказал вам, что ваш выбор — это не воздушный замок? Кто сказал вам, что профессия и семья — это не подмена целей?
Вот и получается что вот это «Право выбора, личная ответственность — это всё ок. Я за двумя руками. » — это просто слова. Вы же в них не верите
Разве вам не приходило в голову, что вы предпочитаете видеть вокруг людей с профессиями и семьями просто потому, что их существование придает вам больше уверенности в вашем собственном выборе — в котором вы сами, наедине с собой, не так уж уверены (вы же тоже завидовали Валентину, а)?
>Я вообще признаю право каждого жить как-угодно, но что сей молодёжный вызов и бунт против правил делает на главной Хабра?
Я замечаю, как вы пытаетесь обесценить то, что сделал автор, выставляя его этаким пацанчиком-бунтарем. Да, тематика не очень айтишная, я согласен. Но на главную, как я понял, пост вывел не автор, а читатели. Мне кажется, это и есть оценка — нужен ли здесь такой пост, разве нет?
Лично мне очень поучительно наблюдать за тем, насколько даже умные люди становятся глухими и слепыми, когда подвергнуты сомнению их фундаментальные убеждения о том, как устроен мир, и как правильно в нем жить. Поучительно — может звучать несколько отстраненно, но я и очень хорошо на своем опыте знаю, насколько болезненно сталкиваться с тем фактом, что никакого правильного способа жить — не существует. Существуют законы природы, все, что сверх — лишь мой личный выбор и моя ответственность за него. И никто и никогда не сможет мне сказать, сколько жизней я мог бы прожить, но не прожил.
Да, канонически в яве все synchronization actions действительно имеют SC-семантику. Модель сама по себе не такая уж обширная. Обширное описание, скорее, есть у причин почему она такая, какая есть, и как к этому пришли — с этой точки зрения, уверен, описание модели C++ будет только еще более обширным. Но есть такая тонкость, что в яве нет undefined behavior по изначальному дизайну языка. Потому примерно половина объема (и 3/4 сложности) модели памяти в яве это именно попытка задать, пусть очень сложную, но все-таки определенную семантику даже коду с гонками. Попытка эта, в общем-то, провалилась — через пару лет после публикации и реализации в этой части были обнаружены баги, которые не позволяли реализовывать важные оптимизации, поэтому существующие реализации JVM фактически нарушают спецификацию где-то в темных углах кода с data race. Есть несколько предложений, как исправить ошибки, но все они не совместимы с текущей версией JMM, поэтому пока все просто закрывают на это глаза. Как я понимаю, этот фэйл является одной из причин почему сейчас гуру concurrency (Ханс Боэм, Даг Ли, и прочие) в один голос повторяют «data race is evil».
Если не брать эту темную сторону, то оригинальная JMM ни разу не сложнее CMM, даже проще — потому что есть только два варианта memory_ordering: relaxed/SC, причем используемый вариант привязан к типу переменной изначально, а не к конкретной операции доступа: есть volatile переменные, все операции с которыми всегда SC, и есть обычные переменные, которые всегда relaxed. Это, собственно, второй ее недостаток — очевидно, что SC несовместимо со scalability, без введения чего-то типа acquire/release/consume нереально линейно масштабироваться дальше пары десятков процессоров. Фактически же, аналоги acquire/release/consume операций уже некоторое время имеются в яве, но это полулегальные операции, потому что официального апдейта JMM с их формализацией нет и не предвидится.
>Мыслить в терминах отношений happens-before и пр. у меня как-то не особо получается.
Ну, среди явистов тоже очень многие рассуждают в терминах барьеров. Как эвристические рассуждения это неплохо, но суть в том, что если вы попытаетесь сделать рассуждения про барьеры и возможные перестановки более строгим — вы, собственно, и получите happens-before notation. Так что лучше уж, как мне кажется, идти сюда сразу же, как вы поймали общую идею алгоритма, и начинаете думать про реализацию.
> В нашем частном случае формальная модель — это happeds-before, synchronized-with и пр. отношения, а интерпретация — в конечном счете, банальные барьеры.
Я думаю, что здесь вы как раз ошибаетесь. Процессоры не господом богом с неба спущены — они разрабатываются инженерами под нужды разработчиков. Я где-то читал, что при разработке JMM были случаи, когда разработчики Intel подправляли спецификацию своих процессоров по итогам обсуждения — и это вполне логично, ибо кому нужны процессоры с набором команд, с которыми неудобно и ненадежно программировать? Судьба пресловутой Alpha очень наглядна в этом смысле. Разумеется, это двусторонний диалог, но это именно диалог — в отличие от законов природы, с которыми особо-то не подискутируешь.
Например, абсолютное большинство современных general purposes процессоров создает иллюзию SC в однопоточном случае — хотя реально они все суперскалярные и используют внеочередное исполнение команд — то есть поддержание иллюзии SC-исполнения на самом деле стоит немалого гемороя их инженерам. Зачем они идут на этот геморой? — Потому что у процессора с менее тривиальной моделью исполнения будут большие проблемы с продажами. Наглядный пример того, как именно процессоры делаются под концепцию, а не наоборот.
… Вообще, у меня есть мнение, что дело здесь не в сложности именно HB, а в том, что программисты сейчас вообще отвыкли серьезно относиться к надежности своего кода. К тому, что корректность алгоритма нужно доказывать, а не «жопой чуять». Если вы когда-нибудь пробовали доказывать корректность однопоточных алгоритмов, вы должны бы заметить, что разница в сложности не такая уж большая. Но для однопоточного кода отладка и тестирование довольно дешевы, дешевле, чем формальное доказательство — уже целое поколение (я в их числе) выросло на идеологии «достаточное количество юнит-тестов является доказательством корректности программы». И когда оказывается, что для многопоточного случая все это на порядки менее эффективно, и мы снова сталкиваемся с необходимостью формального доказательства — вот тут-то и возникает ощущение огромной сложности.
В частности, лично мне кажется, что основной фокус при создании конкурентных алгоритмов должен быть не на том, как избежать возни с формальным доказательством, а на том, как а) избежать многопоточности вообще б) если уж удалось — сделать алгоритм настолько простым, чтобы ошибиться было просто негде. Потому что сколько либо сложный конкурентный алгоритм требует столько внимательности, проверок и перепроверок для своего написания, что это определенно не работа для одного человека. Тут нужно несколько очень опытных специалистов для постоянного ревью, и месяцы тестирования. Это слишком дорого для личных целей, это оправдано либо в качестве обучения, либо в составе очень популярных фреймворков, вокруг которых сильное коммьюнити.
На мой взгляд, data race — это само по себе и есть соглашение. Соглашение о том, какие конкурирующие инструкции работы с памятью мы считаем легальными, а какие ведут к потенциально нехорошему поведению. Т.е. data race — это и есть название для тех паттернов конкурирующего доступа к памяти, которые порождают что-то нехорошее. А обычное определение «запись и чтение/запись из разных потоков, не упорядоченное SA» — просто показывает, какие конфликты можно разрулить на уровне процессора/контролера памяти/компилятора, а какие конфликты требуют участия программиста, потому что эффективно их разрулить автоматически пока невозможно.
>Барьер я могу пощупать, он материален, он воплощается в инструкции процессора. Об отношениях пусть говорят люди более сведущие, например, А.Вильямс.
Я думаю, это просто С-шный бэкграунд сказывается. В яве к happens-before уже привыкли. И это большой вопрос, на самом деле, что первично — нотация happens-before восходит еще к статье Лампорта из 70-х, когда еще писали в терминах явных сообщений между узлами, а не в терминах shared memory.
Если честно, мне как раз не очень понятно, как вы целостно рассуждаете о корректности алгоритма в терминах барьеров? Да еще и кроссплатформенно — т.е. когда вы не можете явно описать, как именно реализован этот барьер на этой архитектуре, что за конкретные действия за ним стоят. На мой взгляд, нотация относительного порядка (aka happens-before) единственный достаточно универсальный способ рассуждать о взаимодействии потоков, это как раз семантика барьеров должна описываться в терминах happens-before. Правда, я не вдавался особо в глубины C++ MM, но я помню дискуссии в concurrency-interest, где Ханс Боэм писал, что явные барьеры в C-MM оставлены в основном для обратной совместимости, чтобы не нужно было переписывать уже существующие алгоритмы с 0. Но вообще, как я понял, он считает их рудиментом, и довольно опасным рудиментом — с той точки зрения, что с ними сложнее писать корректный кроссплатформенный код.
Тут очень двусмысленно звучит — как будто, если вы используете SC-модель доступа к атомикам, то верификация вообще не нужна. Даже если мы говорим только про отсутствие data race (а не про race conditions) — SC-семантика гарантирует вам data race free только и именно для тех переменных, к которым вы обращаетесь через SC-примитивы. Для всех остальных переменных ничего априори не гарантируется, все гарантии необходимо выводить через те самые happens-before, за которыми вы послали так далеко :). А ведь ни одна разумная программа не состоит только из атомиков, так что даже используя только SC-атомики можно легко и непринужденно получить код с гонками за счет «обычных» переменных, которые не несут явной спецификации memory-order. Мне кажется, это ваше утверждение стоит уточнить, во избежание
Отсюда и растут ноги всяких странных вопросов — повидаешь несколько таких случаев, и начинаешь на молоко дуть.
жажду власти удовлетворятьсобеседовать-то?Например, по моему опыту в команде достаточно одного-двух человек с хорошими коммуникативными талантами — они легко компенсируют традиционный недостаток таких талантов у остальных. Причем эту роль вполне может занимать «играющий менеджер»
Я, между прочим, серьезно: мой опыт показывает, что совершенно не важно о чем спрашивать, если копать достаточно глубоко, и слушать достаточно внимательно. «Когда человек входит в комнату — вместе с ним входит вся его жизнь» (с) Можно хоть о политической ситуации в стране говорить — и на примере этого понять, умеет ли человек вообще мыслить, в каких масштабах он способен мыслить, сколько влияющих факторов он способен учитывать в своих ментальных моделях, насколько он склонен подгонять модель под желаемый ответ, и так далее. В этом, как мне кажется, и был исходный смысл гугловских головоломок — который сейчас уже потерян из-за их заезженности, и гугл прав, что от них отказался — но идея-то по прежнему работает.
Единственная проблема возникает если человек вообще на эту тему не хочет говорить — поэтому технические вопросы спрашивать, в среднем по больнице, удобнее — к ним кандидат более-менее готов, и обычно заливается соловьем.
Я не знаю С++ головоломок, но в свое время я очень любил расспрашивать про контракт .equals() в яве (сейчас это уже не актуально, потому что многие тупо выучили) — потому что с небольшими подсказками можно догадаться, и на одном маленьком примере проявляются сразу несколько важных вещей про инженерное дело. Мне было важно видеть реакцию человека.
А в остальном — тонкость в том, что у каждого свой способ ведения интервью, который ему, очевидно, подходит, т.е. позволяет нанимать нужных людей. И это понятно: свести к минимуму процент ложно-положительных исходов можно просто перебирая разные фильтры один за одним, за счет долгого опыта. Гораздо интереснее было бы задаться комплиментарным вопросом: какой у конкретного способа процент ложно-отрицательных результатов? Сколько подходящих людей конкретный способ отсеивает? Еще одна интересная метрика качества: насколько способ воспроизводим? Можете ли вы объяснить свой метод новому коллеге, и быть уверенным, что он будет набирать плюс-минус тех же людей, что и вы?
Мне кажется, что сравнивать методы имеет смысл как раз по этим характеристикам — потому что с точки зрения бизнеса они могут оказаться гораздо важнее.
Фокусироваться на мотивации в ущерб навыкам — это, безусловно, интересная стратегия. Я вижу ее плюсы лично для меня как будущего коллеги — с мотивированными, «горящими» людьми работать приятно (и весело). Но я так же вижу ее и недостатки: далеко не все технические навыки могут быть изучены за разумный период времени. Например: изучить новый язык программирования можно за месяц. Но научиться свободно им пользоваться, интуитивно и лаконично переводя свои ментальные модели сразу в его синтаксические конструкции — нужно несколько лет минимум (и определенный склад ума — некоторые люди и на родном русском-то не могут научиться ясно выражать свои мысли). Как нанимать «за энтузиазм» человека, который не имеет этих нескольких лет опыта? Какая вероятность, что внутренне-мотивированный сотрудник продержится в компании несколько лет, прежде чем его компетенция, наконец, достигнет нужного уровня?
На мой взгляд, ориентироваться на энтузиазм тем эффективнее, чем меньший порог вхождения в вашу область работы. Скажем, на рынке есть 20% сотрудников, которые подходят вам по навыкам, и 10% подходящих по уровню мотивированности и активности жизненной позиции — очевидно, эффективнее фильтровать по жизненной позиции. А если вам подходят 5% сотрудников по навыкам, и те же 10% по горючести — эффективнее отбирать по навыкам. Простейший принцип «сначала фильтруем по признаку с наивысшей селективностью»
Уходите вы уже с ваших C++ — у нас, на яве, такие печеньки для concurrency… :)
Но, конечно, если вы начинаете делать свой собственный memory-management, скажем, заводите пул объектов, чтобы снять нагрузку на GC — вы можете получить ABA назад. Нужно быть очень аккуратным, когда делаете одновременно lock-free и GC-less компоненты.