Ты просто не знаешь условия до конца.
S>я бы добавил к задаче ещё и вопросы про то почему не стоит реализовывать семафор в юзерспейс, какие накладные расходы будут.
Да тут больше не в расходах дело а в том что, чтобы реализовать семафор в ядре, таски нужно перемещать из одной очереди в другую. Поскольку это струкутуры данных ядра, то ты никак не можешь работать с ними из юзер мода. Поэтому и прийдется извращаться через функции других примитивов которые двигают таских по очередям.
S>Идиотизм, как вы говорите, в самом принципе реализовывать семафор в юзерспейс через примитивы синхронизации ядра.
Ну так и решение задачи ведь и основывается на этом самом принципе. Потому и решение и сама задача являются идиотскими. Не так ее решать надо! Лучше поговорить как это сделано в ядре.
S>И задача не для собеседования где хотят проверить владение многопоточностью, а как разминка для ума очень даже не плоха.
Думаю что именно плоха и ее именно доводят до абсурда. Если человек просто понимает что происходит в ядре когда поток ждет на семафоре и когда семафор отпускается — то это уже достаточные знания. Они же хотят именно рабочий код с надуманным условием (вторая часть условия о котором я тут говорю)!
Re[4]: Вопросы на собеседовании про многопоточность
Здравствуйте, Олег К., Вы писали:
KP>>Честно сказать, не понял чем эта задача хуже "8 гномиков встали раком" ОК>Это идиотизм.
Я придерживаюсь несколько другой позиции. Главное на собеседовании это точка для начала общения. Пусть это будет задача на логику, пусть это будет задача ан алгоритмы, пусть это будет задача на многопоточность, пусть это будет задача на сети. Общаться только по выполненным проектам, зачастую, может быть недостаточным, потому и надо с чего-то начать.
KP>>либо переверните однонаправленный список или любая другая задача ни о чем. ОК>А вот это я считаю нормально. Сам бы давать не стал но и нос от нее не ворочал. У развернуть списка хотя бы есть практическая ценность. Другое дело что в реальном коде ее писать не будут т.к. уже есть имплементации, но вот делать семафор в юзер спейсе — у нее нет никакой практической ценности.
Да вот бог его знает насчет практической ценности. По мне так она нулевая, так, не более чем повод "по-трындеть".
KP>>Даже удивительно что народ столько возмущается, неужели написание такой простой херотени доставляет какие-то трудности? ОК>Ну, данный товарищ сам же ее и завалил, хотя у него было время над ней посидеть. Так что не все так просто, особенно учитывая последнии тенденции на интервью. Плюс не забывай что интервью могут проводить полнейшие дурачки которые доведут любую здравую идею до абсурда.
Честно скажу. С "полнейшими дурачками, которые доведут любую здравую идею до абсурда" я за последние несколько лет на собеседованиях не сталкивался не разу (если говорить не о манагерах, а о людях проводящих технические собеседованя; причем, все не адекватные манагеры, с которыми я сталкивался, были не из РФ, но русские).
Re[16]: Вопросы на собеседовании про многопоточность
Здравствуйте, sysenter, Вы писали:
S>Здравствуйте, gangof4, Вы писали:
G>>Однако надо помнить что одно прерывание, всегда может быть прервано другим прерыванием.
S>Soft прерывание может быть вытеснено, но не hard. Собственно для софт прерываний нижняя половина и не используется, а всякие тасклеты и т.п
Я чего-то не совсем понимаю, про что вы говорите. Когда происходит любое прерывание сперва вызывается обработчик ядра, потом последовательно
обработчики всех драйверов которые висят на этом прерывании(которые вызвали request_irq), во время исполнения этого прерывание может быть
прервано прерыванием с более высоким приоритетом(если только не запретить все прерывания в обработчике, хотя на SMP это не поможет).
Более того если драйвер часто должен сам убрать флаг прерывания у девайса, выставившего его(если только это его прерывание, ведь
на одном могут несколько сидеть) иначе прерывание будет вызываться постоянно.
То что исполняется в тасклетах, это вообще не в прерывании устройства не исполняется, а выполняется после, если больше не возникло прерываний.
То есть softirq несмотря на название прерыванием вообще не является, это deferred interrupt handling, который происходит в очереди уже не в контексте
прерывания.
Вообще когда я слышу термин Software Interrupt, мне видятся всякие int 3 в коде, то есть прерывания источником которых служит программа, а не железо.
Re[17]: Вопросы на собеседовании про многопоточность
Здравствуйте, gangof4, Вы писали:
S>>Soft прерывание может быть вытеснено, но не hard. Собственно для софт прерываний нижняя половина и не используется, а всякие тасклеты и т.п G>Я чего-то не совсем понимаю
Hard это аппаратные прерывания, у каждого проца свой стек таких прерываний и они хранятся в hardirq_stack
Soft это функции отложного выполнения (softirq, тасклеты), у каждого проца свой стек таких прерываний и они хранятся в softirq_stack
Обработчик Hard прерывания А может быть прерван другим обработчиком Hard прерывания Б, но не вытеснен т.е. произойдёт вложение одного обработчика прерывания в другой. После отработки обработчика прерывания Б возобновит работу прерванный обработчик А. В случае вытеснения решение о передаче выполнения принял бы шедулер.
Re[18]: Вопросы на собеседовании про многопоточность
Здравствуйте, sysenter, Вы писали:
S>Здравствуйте, gangof4, Вы писали:
S>>>Soft прерывание может быть вытеснено, но не hard. Собственно для софт прерываний нижняя половина и не используется, а всякие тасклеты и т.п G>>Я чего-то не совсем понимаю
S>Hard это аппаратные прерывания, у каждого проца свой стек таких прерываний и они хранятся в hardirq_stack S>Soft это функции отложного выполнения (softirq, тасклеты), у каждого проца свой стек таких прерываний и они хранятся в softirq_stack
S>Обработчик Hard прерывания А может быть прерван другим обработчиком Hard прерывания Б, но не вытеснен т.е. произойдёт вложение одного обработчика прерывания в другой. После отработки обработчика прерывания Б возобновит работу прерванный обработчик А. В случае вытеснения решение о передаче выполнения принял бы шедулер.
Согласен, только я это вообще говоря и сказал вначале: один обработчик может быть прерван другим. Но не вытеснен.
Вообще так cooperative scheduling работает, если была задача, она прерывается обработчиком прерывания, и даже если он
сигналит задаче с более высоким приоритетом, то все равно сперва возобновит работу прерванная, а уж потом когда она отдаст
управление, та которая с более высоким приоритетом.
Re[19]: Вопросы на собеседовании про многопоточность
Здравствуйте, gangof4, Вы писали:
G>Согласен, только я это вообще говоря и сказал вначале: один обработчик может быть прерван другим. Но не вытеснен.
Вы сказали — Однако надо помнить что одно прерывание, всегда может быть прервано другим прерыванием..
На счёт — Но не вытеснен, это я вас дополнил раньше — Soft прерывание может быть вытеснено, но не hard.
Re[4]: Вопросы на собеседовании про многопоточность
Здравствуйте, Олег К., Вы писали:
IID>>>Я любил давать кандидатам задачку на реализацию семафора "вручную". При условии что остальные объекты синхронизации (ивенты, мьютексы и т.д.) у них есть. Казалось бы, но результат удивлял. Мало кто мог реализовать сразу и без ошибок. Многие не могли найти ошибку и/или исправить, когда на неё показывал пальцем.
O>>Стало любопытно. Итого — десять минут на реализацию, плюс еще минут пятнадцать на O>>визуальную проверку, плюс минут двадцать пять на написание и прогон тестового сценария в O>>большом диапазоне потоков и входных значений. При этом кода всего сотня строчек, не больше.
O>>P.S. Гуру по многопоточности себя не считаю. Просто удивляюсь реакции.
ОК>Очередная распальцовка?
Не иначе.
Уж больно я крутой мэн, раз такую задачу осилил.
Re[11]: Вопросы на собеседовании про многопоточность
Здравствуйте, Олег К., Вы писали:
ОК>Возможно но не для тех 50-ти минут личного интервью когда надо поговорить о проектах, спросить знания технологий и рассказать о работе.
Если интервью идет 50 минут, то это не серьезно. Компания собирается получить самый важный ее ресурс — человека. Экономить время интервью — глупость. Нормально, когда интервью идет день, в несколько сессий и проводится разными людьми.
Расспросить о знаниях и проделанной работе это обязательно. В принципе, это уже должно быть в CV и выявлено на телефонном скрининге.
Многие люди с упоением рассказывают о себе, поют как соловьи. Тут как говориться доверяй, но проверяй. Если чел крут, то решить задачку про семафоры для него в пределах часа. Можно спросить про "гору Фудзи", это провокационный вопрос чтобы посмотреть как человек реагирует на стресс.
Re[12]: Вопросы на собеседовании про многопоточность
Здравствуйте, shrecher, Вы писали:
S>Нормально, когда интервью идет день, в несколько сессий и проводится разными людьми.
Это трынцед какой-то, бежать от таких компаний нужно.
S>Можно спросить про "гору Фудзи", это провокационный вопрос чтобы посмотреть как человек реагирует на стресс.
Это про, как сдвинуть гору Фудзи? Человек может подумать, что здесь работают клинические идиоты, встать и спокойно уйти. И будет прав.
Re[13]: Вопросы на собеседовании про многопоточность
Здравствуйте, sysenter, Вы писали:
S>Здравствуйте, shrecher, Вы писали:
S>>Нормально, когда интервью идет день, в несколько сессий и проводится разными людьми.
Вообще-то к крупных компания так и интервьюируют. По гугли "Interview at Microsoft"
The interview day usually comprises meeting with about three to five different employees within Microsoft. A typical schedule might include two interviews in the morning, one lunch interview, and two interviews in the afternoon. The lunch interview can take place in one of Microsoft's various in-house cafeterias or in a restaurant off-campus. In most cases the candidate will interview with two different product teams within a single product group or two entirely different product groups
S>Это трынцед какой-то, бежать от таких компаний нужно.
Тебе и не светит работать в серьезных компаниях.
Re[17]: Вопросы на собеседовании про многопоточность
Здравствуйте, sysenter, Вы писали:
S>Про код, бегло посмотрел, работать похоже будет.
Похоже, не будет. Положим, хотим сделать бинарный семафор, инициализировав предел счетчика 1. Тогда первая нить сделает acquire, увеличив счетчик до 1, и продолжит работу. Вторая нить, получив управление, вызовет acquire, увеличит счетчик до 2 и встанет ждать. Первая нить сделает release, уменьшив счетчик до 1, и не просигналит event, в результате чего вторая нить останется ждать вместо того, чтобы быть просигналенной. Это при беглом просмотре.
bloß it hudla
Re[18]: Вопросы на собеседовании про многопоточность
Здравствуйте, A.Lokotkov, Вы писали:
AL>Здравствуйте, sysenter, Вы писали:
S>>Про код, бегло посмотрел, работать похоже будет.
AL>Похоже, не будет. Положим, хотим сделать бинарный семафор, инициализировав предел счетчика 1. Тогда первая нить сделает acquire, увеличив счетчик до 1, и продолжит работу. Вторая нить, получив управление, вызовет acquire, увеличит счетчик до 2 и встанет ждать. Первая нить сделает release, уменьшив счетчик до 1, и не просигналит event, в результате чего вторая нить останется ждать вместо того, чтобы быть просигналенной. Это при беглом просмотре.
Тут тонкость еще в том, что SetEvent (освобождение) может быть вызвана двумя или более покидающими
семафор потоками в очень короткий промежуток времени. При этом велик риск того, что войдет только
один поток-новичок. Если семафор рассчитан на одновременное обслуживание нескольких потоков,
то при высокой конкуренции вполне вероятна ситуация, при которой он будет большую часть времени
захвачен только одним-двумя.
Re[12]: Вопросы на собеседовании про многопоточность
ОК>>Возможно но не для тех 50-ти минут личного интервью когда надо поговорить о проектах, спросить знания технологий и рассказать о работе.
S>Если интервью идет 50 минут, то это не серьезно. Компания собирается получить самый важный ее ресурс — человека. Экономить время интервью — глупость. Нормально, когда интервью идет день, в несколько сессий и проводится разными людьми.
Тут как бы палка о двух концах. Поговорить надо и желательно подольше, но вместе с тем мало кому понравится экзамен в несколько часов, и если человека не особо прижимают жизненые обстоятельства, то он пошлет таких в том или ином виде. Так что соблюдать баланс все-таки прийдется.
S>Расспросить о знаниях и проделанной работе это обязательно. В принципе, это уже должно быть в CV и выявлено на телефонном скрининге.
S>Многие люди с упоением рассказывают о себе, поют как соловьи. Тут как говориться доверяй, но проверяй. Если чел крут, то решить задачку про семафоры для него в пределах часа. Можно спросить про "гору Фудзи", это провокационный вопрос чтобы посмотреть как человек реагирует на стресс.
Это вообще какой-то идиотизм спрашивать про гору Фудзи. Особенно когда этим занимаются какие-то "Рога и Копыта."
Re[14]: Вопросы на собеседовании про многопоточность
S>Вообще-то к крупных компания так и интервьюируют. По гугли "Interview at Microsoft"
Вообще-то сам Майкрософт отошел уже от таких задач как про гору Фудзи. Так что...
Но ладно. Ради Майкрософта я, к примеру, готов потерпеть задачи про гору Фудзи, но когда это дают какие-то "Рога и Копыта"
S>>Это трынцед какой-то, бежать от таких компаний нужно.
S>Тебе и не светит работать в серьезных компаниях.
Re[5]: Вопросы на собеседовании про многопоточность
Здравствуйте, shrecher, Вы писали:
S>Здравствуйте, sysenter, Вы писали:
S>>Здравствуйте, shrecher, Вы писали:
S>>>Нормально, когда интервью идет день, в несколько сессий и проводится разными людьми.
S>The interview day usually comprises meeting with about three to five different employees within Microsoft. A typical schedule might include two interviews in the morning, one lunch interview, and two interviews in the afternoon. The lunch interview can take place in one of Microsoft's various in-house cafeterias or in a restaurant off-campus. In most cases the candidate will interview with two different product teams within a single product group or two entirely different product groups
S>>Это трынцед какой-то, бежать от таких компаний нужно. S>Тебе и не светит работать в серьезных компаниях.
MS давно не спрашивает про Фудзи)
Re[15]: Вопросы на собеседовании про многопоточность
Здравствуйте, andy., Вы писали:
A>MS давно не спрашивает про Фудзи)
Читать умеешь? "это провокационный вопрос чтобы посмотреть как человек реагирует на стресс." Можно спросить, что вы будете делать если вас заберут инопланетяне?.
Смысл таких вопросов просто что человек делает в не привычной для него ситуации.
Re[6]: Вопросы на собеседовании про многопоточность
Здравствуйте, Олег К., Вы писали:
O>>Не иначе. O>>Уж больно я крутой мэн, раз такую задачу осилил.
ОК>Ну это ты так думаешь что осилил. IID вон тоже так думал, однако показал полное непонимание как работают семафоры.
С чувством юмора вообще все в порядке ? Или мне надо было поставить какой-нибудь смайлик ?
ОК>И прошу тебя, не надо мне сюда ставить очередной самопальный семафор.
Изволь объяснить, за что минусы поставил.
Мне, вообще-то, по барабану, но все-таки интересно, с чем именно ты вот в этой цитате не согласен:
>okman: Тут тонкость еще в том, что SetEvent (освобождение) может быть вызвана двумя или более покидающими
семафор потоками в очень короткий промежуток времени. При этом велик риск того, что войдет только
один поток-новичок. Если семафор рассчитан на одновременное обслуживание нескольких потоков,
то при высокой конкуренции вполне вероятна ситуация, при которой он будет большую часть времени
захвачен только одним-двумя.
Re[11]: Вопросы на собеседовании про многопоточность
S>Это про какую версию ядра 2.6 или 2.4? Книгу какого года издания читаете? S>Ядро Linux вытесняемое и потоки ядра также могут вытеснены, это 100% информация.
По-человечески вытесняемое оно становится только с RT_PREEMPT patch. Это отдельное ядро, и у SuSE (Novell) оно вообще идет как отдельный Add-On продукт к своему SLES'у. Код ядра там достаточно сильно изменен (патч большой), как раз в тех местах, где синхронизация. В силу специфики моей нынешней работы там приходится периодически копаться (нам нужен soft realtime, а без вытеснения ядра это невозможно в принципе).
Но, боюсь, "очень далеки они от народа", такие варианты линукса (а уж как на этих ядрах плохо работают KDE, Eclipse и gdb — вообще песня, которая стоном зовется).
