Здравствуйте, SkyDance, Вы писали:
N_>>Создавать СОМ обьекты на стеке Вообщето их принято фабрикой создавать, и согласовать размещение обьекта с фабрикой не является проблемой.
SD>При чем тут стек? SD>Я же написал там про реализацию IClassFactory с применением пула готовых объектов (чтобы сэкономить на выделении памяти и инициализации).
SD>Стек — это уже было в рамках обсуждения delete this; а не про конкретно СОМ-объекты.
в СОМе фабрика и сам класс поставляются вместе, и создавать обьект как-то иначе, чем через его собственную фабрику нельзя. А обьекту со свой фабрикой договориться о том как правильно удаляться не является проблемой
Re[2]: Вопросы на собеседовании про многопоточность
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Потоки работающие в рамках DLL. Засады, решения...
А можете перечислить? А то с этим я редко работал. Знаю только про однопоточность DllMain — что потоки, запущенные в ней, будут приостановлены до конца инициализации длл-ки, т.е. в дллмайн нет смысла ждать каких-то эвентов от рабочих потоков, повиснем
Re[3]: Вопросы на собеседовании про многопоточность
Здравствуйте, Aleksey_NN, Вы писали:
КД>>Потоки работающие в рамках DLL. Засады, решения...
A_N>А можете перечислить? А то с этим я редко работал. Знаю только про однопоточность DllMain — что потоки, запущенные в ней, будут приостановлены до конца инициализации длл-ки, т.е. в дллмайн нет смысла ждать каких-то эвентов от рабочих потоков, повиснем
Про DllMain — это понятно. В ней нельзя запускать/останавливать и прочие операции с потоками. Это в Рихтере описано.
Мне больше нравится другое — борьба с выгрузкой DLL, которая содержит активные потоки.
На текущий момент у меня работает схема — есть рабочие потоки и есть поток супервизора.
поток супервизора
— блокирует DLL в памяти (вызывает LoadLibrary)
— проверяет состояние всех рабочих потоков (они регистрируются в глобальном списке)
если рабочий поток стал неактивным, то поток супервизор удаляет его из списка
как только список опустошился, поток супервизора завершает работу через вызов FreeLibraryAndExitThread
это позволяет избежать всяких специальных экспортируемых функций DLL типа ShutdownServer, которые в случае COM-сервера в DLL бессмысленны.
Вообщем, здесь ключевой вещью является FreeLibraryAndExitThread. Кстати, тоже есть в Рихтере.
----
Поскольку DLL, это как правило — COM сервер, то я эксплуатирую еще одно правило: как только уничтожается последний COM-объект, я завершаю все рабочие потоки. Точнее уничтожаю пул потоков. Супервизор сам завершит свою работу. Я вообще не очень сильно исследовал этот момент, решил не рисковать и завершать всю активность внутрях своего модуля
----
Кстати говоря, я не уверен, но по-моему дело обстоит именно так — DLL-ные модули которые будут работать в произвольной многопоточной среде следует линковать только с MT-DLL стандартной библиотеки. Статика может спровоцировать всякие нехорошие проблемы.
Я вообще всегда юзаю только MT-DLL рантайма, независимо от типа проекта. Чисто на всякий случай
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Re[8]: Вопросы на собеседовании про многопоточность
Здравствуйте, IID, Вы писали:
IID>А у тебя кроме чёрного и белого ещё цвета есть ? Если нужен человек, разбирающися в многопоточности — надо брать человека, разбирающегося в многопоточности. Это не значит что нужен мега-гуру, но и абсолютно не шаращяего тоже брать не нужно. Интересно, почему такой баттхёрт от примитивной задачки ?
потому что здесь популярно мнение, что на собеседовании задачки давать нельзя, типа то, что человек не умеет решать такие задачи ничего не значит. а говорить надо о предыдущем опыте, если опыт хороший — значит и человек толковый.
Доля истины в этом есть, но очень небольшая.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[8]: Вопросы на собеседовании про многопоточность
Здравствуйте, IID, Вы писали:
IID>А у тебя кроме чёрного и белого ещё цвета есть ? Если нужен человек, разбирающися в многопоточности — надо брать человека, разбирающегося в многопоточности. Это не значит что нужен мега-гуру, но и абсолютно не шаращяего тоже брать не нужно. Интересно, почему такой баттхёрт от примитивной задачки ?
Твой светофор — это не примитивная задача, а кусок бессмысленного говнокода.
Чтобы разбираться в многопоточности, нужно:
1. Знать, зачем, когда и почему необходимо иметь много потоков.
2. Знать, какие грабли из этого отрастают как их избегать.
Все.
Ниасилившие эти две проблемы занмаются конструированием велосипедов.
Re[13]: Вопросы на собеседовании про многопоточность
Здравствуйте, Madruel, Вы писали:
M>Здравствуйте, мыщъх, Вы писали:
М>>в том-то и дело. до сих пор не могу понять откуда такая любовь к сценариям -- один поток заталкивает элементы в объект, а другой их оттуда выпихивает. вроде бы ясно, что кто заталкивает, тот и выпихивать должен, а остальные всего лишь собщать ему, что данный элемент в очереди на выпих.
M>Интересно, а как преобразовать задачу Producer-consumer, чтобы избежать ситуации "один поток заталкивает элементы в объект, а другой их оттуда выпихивает"? (Естественно, помимо отказа от многопоточности вообще)
через API ес-но. писал же. есть поток-агент, работающий с данными, нужными остальным потокам. эти потоки обращаются к данным не напрямую, а через агента. потоки вызывают API агента в случайное время, и в это время происходит модификация очередей каждого потока на обращение к агенту. очереди находятся в локальной памяти потоков (не TLS, а просто буфер). поток-агент к ним обращается только при вызове его API, что обеспечивает прозрачную синхронизацию. главнй минус этой схеме -- памяти требуется больше. главный плюс -- системно-независимо, т.к. не используются объекты синхронизации, а потому работает и на ANSI C.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Re[4]: Вопросы на собеседовании про многопоточность
Здравствуйте, Паблик Морозов, Вы писали:
ПМ>Здравствуйте, andy., Вы писали:
A>>А что, кстати, плохого в вопросах про мьютексы/сигналы/ивенты. Разве эти примитивы не надо знать в первую очередь ?
ПМ>Когда вы в последний раз реализовывали мьютекс/сигнал/эвент?
ПМ>Тут товарищь писал, что большая часть собеседуемых не может нормально написать семафор, так оно и есть, и заниматься написанием семафоров вместо решения прикладных задач — это все равно что в жопу долбиться. Чтобы не долбиться в жопу, любой нормальный инженер разработает методы автоматизации рутинных задач, часть из которых я перечислил, а если он продолжает стойко преодолевать надуманные трудности — то он, скорее всего, не инженер, а педераст. Общения с педерастами следует избегать, они ведь и нормального человека зашкварить могут, поэтому как только речь заходит о реализации семафора (о которой, кстати, можно прочитать в википедии, поэтому само по себе это знание особой ценности не представляет) следует сразу уходить с собеседования, ибо нормальному пацану в петушиной хате западло работать.
Смешно. А если тебе на собеседовании предложат написать процедурку умножения целых чисел, используя только сложение и сдвиг, ты их тоже педерастами обзовешь? Или ты и на собеседованиях только нетленку ваяешь?
Re[9]: Вопросы на собеседовании про многопоточность
Здравствуйте, Олег К., Вы писали:
HN>>>Согласен, если есть конкретные требования, тут уж ничего не поделаешь. HN>>>Просто обидно, когда чувствуешь, что "могешь" скорее всего, а опыта поднабраться негде.
IID>>Более того, "скорее всего" означает кучу говнокода, который на первый взгляд корректен,
ОК>Этот твой user-space semaphore и есть самый что ни на есть гавнистый говнокод, как бы аккуратно его не написали. А ты даже и не понимаешь этого.
Это задача на собеседовании, а не production код. Ты хочешь мне доказать, что если человек не может сделать семафор, то он разбирается в многопоточности, или что ? Насчёт говнистости тоже вопрос открыт. Может твоя реализация и будет "говнистым говном" (с) твой, но можно написать так, что по накладным расходам будет не сильно отличаться от штатного.
IID>>а на самом деле содержит кучу багов. А в многопоточном окружении ловить race condtition-ы то ещё "удовольствие". Опыта поднабраться всегда есть где =) Самостоятельные проекты, изучение текущего продукта, написанного более опытными товарищами, изучение стороннего открытого кода. Только для этого надо тратить время и силы, а особо ленивые уповают что их возьмут и так, а там авось как-нибудь научатся, да что-нибудь напишут, а другие пусть исправляют.
ОК>Да ничего такого в этой многопоточности и синхронизации нет и зачастую она не нужна.
Ты не прав. Есть разные неочевидные на первый взгляд вещи. А про нужность вообще бред. Если тебе/твоей конторе не нужна — отучайся говорить за всех.
ОК>Нужно просто понимать что такое потоки, как происходит их переключение, проблемы с ними связанные и примитивы синхронизации. Ну и иметь голову на плечах.
Вау! Спасибо кэп. А теперь вопрос: если всё перечисленное имеется — какова сложность выполнения задачи на собеседовании ? Верно, никакой сложности. Задача тривиальная.
ОК>А на интервью всего не спросить.
Логично. Но это же не значит что теперь и спрашивать не надо.
IID>>В ключе моего примера с семафором достаточно иметь базовые знания о примитивах синхронизации, да нормальную логику. Ну и аккуратность. Чтобы учесть все варианты поведения кода. Никаких супер-скиллов не нужно. Если кандидат не в состоянии решить такую задачу то и учить его бесполезно. Пусть базу подтягивает.
ОК>Повторюсь опять. Тебе череп на мозг не давит?
Попаболь detected. Что же так тебя зацепило ?
ОК>Ты тут разглагольствуешь о какой-то базе однако уже в котором посту забыл упомянуть еще одно важное и надуманное условие задачи.
Это какое я условие забыл упомянуть ?
ОК>Также и на интервью, скорее всего.
О, попёрли фантазии.
kalsarikännit
Re[9]: Вопросы на собеседовании про многопоточность
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, IID, Вы писали:
IID>>А у тебя кроме чёрного и белого ещё цвета есть ? Если нужен человек, разбирающися в многопоточности — надо брать человека, разбирающегося в многопоточности. Это не значит что нужен мега-гуру, но и абсолютно не шаращяего тоже брать не нужно. Интересно, почему такой баттхёрт от примитивной задачки ?
L>Твой светофор — это не примитивная задача, а кусок бессмысленного говнокода.
Мой семафор это отличный индикатор. Проверено неоднократно. Чем лучше кандидат справлялся с ним, тем меньше потом багов с потокам было у него в коде. А половина тех кто сливали и на другие вопросы ответить толком не могли.
L>Чтобы разбираться в многопоточности, нужно: L>1. Знать, зачем, когда и почему необходимо иметь много потоков. L>2. Знать, какие грабли из этого отрастают как их избегать.
Если не можешь осилить семафор, то п2 сфейлен.
L>Все. L>Ниасилившие эти две проблемы занмаются конструированием велосипедов.
Да причём тут велосипед. Ты читать умеешь ? Зто задача для собеседования. А не код в production. Я понимаю, что подменять понятия это излюбленный на RSDN приём, но не до такой же степени.
kalsarikännit
Re[10]: Вопросы на собеседовании про многопоточность
Здравствуйте, IID, Вы писали:
IID>Может твоя реализация и будет "говнистым говном" (с) твой, но можно написать так, что по накладным расходам будет не сильно отличаться от штатного.
Может представите свою реализацию где накладные расходы будут не сильно отличаться от ядерного семафора?
Re[8]: Вопросы на собеседовании про многопоточность
Здравствуйте, andy., Вы писали:
A>В винде внутри процесса можно CriticalSection использовать, а между процессами Messaging, разве нет ?
Между процессами можно использовать любые объекты ядра, имеющие описатель в User land и поддерживающие синхронизацию: Synchronization Objects. Второй процесс получит их либо открыв по имени, либо в результате дупликации описателей процессом-владельцем.
kalsarikännit
Re[6]: Вопросы на собеседовании про многопоточность
Здравствуйте, Олег К., Вы писали:
IID>>>Но если человек не может написать сам семафор, делает логические ошибки, ошибки синхронизации, или даже не знает что такое семафор — то в многопоточном программировании он лопух полный, и его за километр нельзя подпускать к таким проектам.
MP>>Интересно, что ж вы там такое напедалить умудрились, что теперь без знания ручного семафора людей на проект брать опасно.
ОК>Сто процентов что что-нибудь да напедалили в этом стиле. Не семафор так что-то другое. Возможно даже все.
Вот и экстрасенсы подтянулись. Испытывающие баттхёрт от того, что считают задачку на написание самопального семафора за гранью знаний спеца по многопоточному программированию, которым сами, безусловно, являются
kalsarikännit
Re[5]: Вопросы на собеседовании про многопоточность
Здравствуйте, Олег К., Вы писали:
A>>>У вас в проекте много "ручных" семафоров, если не секрет конечно ?
IID>>Ну вот, начинается. Рассуждения в ключе "если не используется то я знать не обязан". Ручных семафоров, разумеется, нет. Но если человек не может написать сам семафор, делает логические ошибки, ошибки синхронизации, или даже не знает что такое семафор — то в многопоточном программировании он лопух полный, и его за километр нельзя подпускать к таким проектам.
ОК>Реализовать семафор в кернел моде намного проще и понятнее этого изврата который ты хочешь увидеть в юзер моде при помощи других примитивов.
Да что вы такое говорите! Много вы семафоров в кернелмоде реализовали ? Как предполагается делать семафор в кернелмоде без других объектов синхронизации ? Расскажите, очень интересно послушать. Особенно в ключе "намного проще и понятнее".
ОК>ЗЫ. Ты такой умный! Тебе череп мозг не жмет? (с)
Написать вручную семафор это уже признак великого ума ? Я бы по другому сказал: средний уровень знаний стремительно деградирует, раз такая примитивная задача вызывает столько ненависти от ущемлённых.
kalsarikännit
Re[3]: Вопросы на собеседовании про многопоточность
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, IID, Вы писали:
IID>>Я любил давать кандидатам задачку на реализацию семафора "вручную". При условии что остальные объекты синхронизации (ивенты, мьютексы и т.д.) у них есть. Казалось бы, но результат удивлял. Мало кто мог реализовать сразу и без ошибок. Многие не могли найти ошибку и/или исправить, когда на неё показывал пальцем.
KP>Честно сказать, не понял чем эта задача хуже "8 гномиков встали раком" либо переверните однонаправленный список или любая другая задача ни о чем. Даже удивительно что народ столько возмущается, неужели написание такой простой херотени доставляет какие-то трудности?
Я сам в шоке (ц)
kalsarikännit
Re[11]: Вопросы на собеседовании про многопоточность
Здравствуйте, sysenter, Вы писали:
S>Здравствуйте, IID, Вы писали:
IID>>Может твоя реализация и будет "говнистым говном" (с) твой, но можно написать так, что по накладным расходам будет не сильно отличаться от штатного.
S>Может представите свою реализацию где накладные расходы будут не сильно отличаться от ядерного семафора?
Здравствуйте, IID, Вы писали:
IID>Да что вы такое говорите! Много вы семафоров в кернелмоде реализовали ? Как предполагается делать семафор в кернелмоде без других объектов синхронизации ? Расскажите, очень интересно послушать. Особенно в ключе "намного проще и понятнее".
Расскажу, в ядре Linux семафоры реализованы через спинлоки и отключение прерываний, спинлок это просто цикл.
Сразу видно "специалиста" по ядерным примитивам синхронизации.
Re[12]: Вопросы на собеседовании про многопоточность
реализацию "в ядре" от мега-гуру Олег К. Дадим ему шанс блеснуть. А потом я свой скромный вариант выложу.
S>Тут я вам помогу, пример семафора из Linux S>Ждем вашу реализацию для сравнения.
Здравствуйте, sysenter, Вы писали:
S>Здравствуйте, IID, Вы писали:
IID>>Да что вы такое говорите! Много вы семафоров в кернелмоде реализовали ? Как предполагается делать семафор в кернелмоде без других объектов синхронизации ? Расскажите, очень интересно послушать. Особенно в ключе "намного проще и понятнее".
S>Расскажу, в ядре Linux семафоры реализованы через спинлоки и отключение прерываний, спинлок это просто цикл.
Фигню ты несёшь. pthread-ные семафоры реализованы совершенно не так.
S>Сразу видно "специалиста" по ядерным примитивам синхронизации.
Ох уж мне эти экстрасенсы. Покажи-ка мне нормальную ядерную реализацию, взаимодествующую с планировщиком.
Вообщето их принято фабрикой создавать, и согласовать размещение обьекта с фабрикой не является проблемой. 
