Как определить программиста, хорошо разбирающегося в многопоточном программировании?

Question

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

Что бы вы искали?

Answer 1

Отведите команду в кофейню за напитками, убедитесь, что в наличии только 1 ложка.

Бонус: тот, кто размешивает кофе до того, как другие добавят сахар, проигрывает.

---

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

Answer 2

Потоки часто настолько сложны и настолько специфичны для реализации, что, я думаю, единственно верный способ оценить это - поставить им фиктивную задачу (в желаемой архитектуре) и «иметь ее». Что-то, что включает в себя конкурирующих читателей / писателей / рабочих - и пользовательский интерфейс, если это необходимо.

Конечно ... вам также нужно, чтобы кто-то был квалифицирован, чтобы оценить их усилия ...

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

Точно так же инструменты / подходы меняются в зависимости от структуры. В OCAML / F # и т. Д. очень другой код многопоточности для Java / C # - и даже это меняется в зависимости от версии (см. Parallel Extensions / TPL и такие вещи, как ReaderWriterLockSlim в 3.5 против ReaderWriterLock в 2.0)

Answer 3

Команде понадобится как минимум один человек, имеющий опыт в этом. Особенно архитектор (если у вас есть эта роль) должен быть опытным. Чтобы проверить: обычно это видимо в резюме людей (если внешнее). В противном случае, просто задайте несколько открытых вопросов. Как: как бы вы справились с синхронизацией между двумя задачами Я был бы заинтересован в: * отношение * процесс (т. е. это хороший знак, если у людей есть вопросы) и тогда вы все равно можете добавить , почему вы думаете, что это хорошее решение?

Конечно, вам все еще нужен кто-то, кто сможет судить о правильности их ответов, поскольку возможны несколько правильных решений.

Answer 4

Дайте им сломанную многопоточную проблему и попросите их исправить.

Спросите их:

• Что такое транзакционная память?
• Почему люди ненавидят совместный государственный параллелизм?
• Что такое livelock?
• Кто такие актеры?
• Какое дело у тех столовых философов?
• Как вы структурируете сложные многопоточные приложения?
• Почему только 1 поток пользовательского интерфейса?
• Что такое мьютекс? Что такое семафор?
• Что такое блокировка чтения и записи и зачем вы ее используете?
• Когда пора создавать новую тему?
• Что такое зеленые нити, что такое волокна?

Сложно найти специалиста в той области, для которой вам понадобится эксперт.

Answer 5

Я бы искал чертовски хороших программистов.

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

Answer 6

Пусть они объяснят концепцию "видимости" в Java. Это настолько сложно, что вы можете сделать это правильно только при серьезном бывшем воздействии.

Answer 7

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

Answer 8

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

Answer 9

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