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

Здравствуйте, sysenter, Вы писали:

S>Здравствуйте, andy., Вы писали:

A>>А что, кстати, плохого в вопросах про мьютексы/сигналы/ивенты. Разве эти примитивы не надо знать в первую очередь ?

S>Обычно при разработке на плюсах используют boost, как давно boost знаком с виндовыми Event?

http://www.boost.org/doc/libs/1_46_1/doc/html/thread/synchronization.html#thread.synchronization.condvar_ref

Здравствуйте, IID, Вы писали:

IID>Здравствуйте, andy., Вы писали:

A>>Здравствуйте, IID, Вы писали:

IID>>>Здравствуйте, Aleksey_NN, Вы писали:

IID>>>Я любил давать кандидатам задачку на реализацию семафора "вручную". При условии что остальные объекты синхронизации (ивенты, мьютексы и т.д.) у них есть. Казалось бы, но результат удивлял. Мало кто мог реализовать сразу и без ошибок. Многие не могли найти ошибку и/или исправить, когда на неё показывал пальцем.

A>>У вас в проекте много "ручных" семафоров, если не секрет конечно ?

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

А если кандидат пишет под линукс и не знает что в далёком виндовс есть семафоры? Сразу в утиль?

Здравствуйте, XuMuK, Вы писали:

XMK>http://www.boost.org/doc/libs/1_46_1/doc/html/thread/synchronization.html#thread.synchronization.condvar_ref

Conditional var не равнозначно event, не хранит состояние — ручной/авто сброс. В целом это платформозависимые мелочи, готов согласиться с предложенным вариантом.

Здравствуйте, XuMuK, Вы писали:

XMK>А если кандидат пишет под линукс и не знает что в далёком виндовс есть семафоры? Сразу в утиль?

В Linux Posix и IPC семофоры есть же

Здравствуйте, HolyNick, Вы писали:

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

Думаешь это кого-нибудь интересует ? Есть кандидат А, который не поленился изучить технологию Х. И есть кандидат Б, которому всё некогда и лениво. Работодателю плевать на причины, по которому Б не знает Х. Пусть Б ноет дальше. Или идёт учить Х в институт (смешно, ага).

Здравствуйте, XuMuK, Вы писали:

XMK>А если кандидат пишет под линукс и не знает что в далёком виндовс есть семафоры? Сразу в утиль?

А причём тут вообще ОС ? Семафоры базовая концепция примитивов синхронизации. В линуксе есть в том числе (Posix semaphores). Таки да, в твоей постановке: не знает что такое семафоры — сразу в утиль

Здравствуйте, IID, Вы писали:

IID>Здравствуйте, XuMuK, Вы писали:

XMK>>А если кандидат пишет под линукс и не знает что в далёком виндовс есть семафоры? Сразу в утиль?

IID>А причём тут вообще ОС ? Семафоры базовая концепция примитивов синхронизации. В линуксе есть в том числе (Posix semaphores). Таки да, в твоей постановке: не знает что такое семафоры — сразу в утиль

О, и правда =) Я как-то за все годы пользовался либо pthread'ом либо бустом, а о семафорах читал года 4 назад, во время подготовки к очередному собеседованию (где они не понадобились), и кроме того что это базовый примитив синхронизации ничего не вспомнил, вот и удивился. А винда к тому, что там семафорами наверное приходится пользоваться, в отличии от. Ну значит меня в утиль, договорились =)

Здравствуйте, IID, Вы писали:

IID>А с такой логикой надо брать вообще всех подряд Ведь всё можно усвоить и всему обучить. Нафиг-нафиг. В нашем случае необходимо было знание многопоточности сразу, без обучения. Это во-первых. А во-вторых, если кандидат декларирует знание многопоточности и валится на такой задачке — о чём вообще может идти речь ?

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

Здравствуйте, landerhigh, Вы писали:

L>Здравствуйте, IID, Вы писали:

IID>>А с такой логикой надо брать вообще всех подряд Ведь всё можно усвоить и всему обучить. Нафиг-нафиг. В нашем случае необходимо было знание многопоточности сразу, без обучения. Это во-первых. А во-вторых, если кандидат декларирует знание многопоточности и валится на такой задачке — о чём вообще может идти речь ?

L>Мой личный опыт показывает, что лучше взять полного лопуха в многопоточности, чем специалиста по lock-free очередям, наколенным семафорам и прочими обедающими философами.

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

L>От последних вреда на два десятичных порядка больше.
Не уловил мысль. Давай, развивай.

Здравствуйте, XuMuK, Вы писали:

XMK>А винда к тому, что там семафорами наверное приходится пользоваться, в отличии от.

Опять винда, эка тебе она покоя не даёт. Повторяю, я вообще ОС не упоминал.

XMK>Я как-то за все годы пользовался либо pthread'ом либо бустом, а о семафорах читал года 4 назад, во время подготовки к очередному собеседованию (где они не понадобились)

Ну если чего-то не знаешь, то и использовать это не будешь. Логично ? А если серъёзно — не знать что такое семафор это ещё не фатально (хотя и тревожный сигнал). Но вот если тебе объясняют как он работает, а ты не можешь его реализовать — то всё плохо.

Здравствуйте, XuMuK, Вы писали:

XMK>Здравствуйте, IID, Вы писали:

IID>>Здравствуйте, XuMuK, Вы писали:

XMK>>>А если кандидат пишет под линукс и не знает что в далёком виндовс есть семафоры? Сразу в утиль?

IID>>А причём тут вообще ОС ? Семафоры базовая концепция примитивов синхронизации. В линуксе есть в том числе (Posix semaphores). Таки да, в твоей постановке: не знает что такое семафоры — сразу в утиль

XMK>О, и правда =) Я как-то за все годы пользовался либо pthread'ом либо бустом, а о семафорах читал года 4 назад, во время подготовки к очередному собеседованию (где они не понадобились), и кроме того что это базовый примитив синхронизации ничего не вспомнил, вот и удивился. А винда к тому, что там семафорами наверное приходится пользоваться, в отличии от. Ну значит меня в утиль, договорились =)

В винде внутри процесса можно CriticalSection использовать, а между процессами Messaging, разве нет ?

Здравствуйте, IID, Вы писали:

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

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

Здравствуйте, мыщъх, Вы писали:

М>вероятно, имелась ввиду ситуация, когда ЦП1 пишет в память, находящейся в кэше ЦП2. контроль на самом деле есть. не хочешь, чтобы возникала такая ситуация -- не вызывай ее.

М>рассмотрим список в котором добавление/удаление элементов осуществляется редко, а вот изменение элементов -- часто и с разных ЦП. очевидно, что вынос ссылок в отдельную область памяти существенно ускорит работу со списком.

Угу. Я бы был рад услышать про MESI, про store buffers, read/write memory barriers, prefetching etc. Много о чем поговорить можно. Но это так, мысли вслух

Здравствуйте, Aleksey_NN, Вы писали:

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

Потоки работающие в рамках DLL. Засады, решения...

Здравствуйте, Ulitka, Вы писали:

U>Здравствуйте, мыщъх, Вы писали:

М>>вероятно, имелась ввиду ситуация, когда ЦП1 пишет в память, находящейся в кэше ЦП2. контроль на самом деле есть. не хочешь, чтобы возникала такая ситуация -- не вызывай ее.

М>>рассмотрим список в котором добавление/удаление элементов осуществляется редко, а вот изменение элементов -- часто и с разных ЦП. очевидно, что вынос ссылок в отдельную область памяти существенно ускорит работу со списком.

U>Угу. Я бы был рад услышать про MESI,
кстати, да. понимание протокола позволяет оптимизировать программы. во всяком случае не будет ситуации, когда два и более ЦП "молотят" одну область памяти и оба туда интенсивно читают/пишут. стоимость одного обращения к ячейке памяти резко возрастает и дешевле вырубить остальные ЦП на фиг, чем так параллелить задачу.

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

U> prefetching etc. Много о чем поговорить можно.
U> Но это так, мысли вслух
ИМХО лучший способ избежать багов -- это отказаться от работы с разделяемыми данными. в большинстве случаев это вполне возможно. а если работа с разделяемыми данными необходима, то вводить поток-посредник. например, у нас есть список, который мы хотим модифицировать из разных потоков. если потоки модифицируют его напрямую -- нужна синхронизация. если же список модифицирует только один поток, а остальные потоки к нему обращатся с запросами, причем запросы ставятся в раздельные очереди (по одной на каждый поток), то в этом случае разделяемых данных нет. ну то есть они, конечно, есть, но исключительно в схеме поток_агент <==> поток_с_запросом, но тут синхронизация тривиальная.

Здравствуйте, Ulitka, Вы писали:

U>>>А я бы попросил объяснить как CPUs между собой договариваются, кто и какие данные модифицирует, и как гарантируется то, что другие CPU не прочитают "грязные" данные. Вполне себе интересная тема.

Прикладному программисту это по-барабану.

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Здравствуйте, Ulitka, Вы писали:

U>>>>А я бы попросил объяснить как CPUs между собой договариваются, кто и какие данные модифицирует, и как гарантируется то, что другие CPU не прочитают "грязные" данные. Вполне себе интересная тема.

КД>Прикладному программисту это по-барабану.

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

Здравствуйте, мыщъх, Вы писали:

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

Здравствуйте, Ulitka, Вы писали:

U>Здравствуйте, мыщъх, Вы писали:

U> мыщъх, не могу не согласиться. Но как мало людей об этом знают...
я тоже этим удручаюсь. и еще удручаюсь тем, что стремятся параллелить на самом низком уровне, хотя классический контрпример -- написать компилятор, поддерживающий N ЦП очень сложно (если вообще возможно), но легко заставить make пускать компилятор на разных ЦП. и... никаких проблем работы с разделяемыми данными, синхронизаций и т.д. и т.п.

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

у меня вот программа на 10K+ строк многопоточная и многоцпшная. только она об этом не знает, т.к. в момент иницилизации экземпляра "движка" функция init возвращает handle, в котором есть указатель на память, в которой расположены все необходимые данные, настройки и промежуточные результаты. грубо говоря, каждый экземпляр ведет себя так, как будто он тут один, а если им нужно взаимодействовать -- на это есть API. и хотя API у меня тупое (там данные копируются из локального хранилища одного потока в локальное хранилище другого), это все же быстрее, чем средства синхронизации, размазанные по всей программе.