Re[18]: Вопросы на собеседовании про многопоточность
От: sysenter  
Дата: 27.05.11 20:12
Оценка:
Здравствуйте, IID, Вы писали:

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


Ну, не составляет, вопрос то был в том, что реализовать в юзер мод семафор с производительностью близкой к КМ не реально. Что вы удачно и подтвердили.
Re[12]: Вопросы на собеседовании про многопоточность
От: sysenter  
Дата: 27.05.11 20:20
Оценка:
Здравствуйте, gangof4, Вы писали:

G>Каюсь, ядро 2.4. А что 2.6 вытесняемое? Дайте ссылку что-ли..


В той же самой книге только 3-е издание за 2005 год откройте главу 7 про планирование процессов.

G>Как я безнадежно отстал от жизни..А верхняя и нижняя это как?


Это архитектурное разделение драйвера на приём данных и их обработку.
Нижняя половина отрабатывает сразу, как поступает прерывание от устройства. Нижняя половина не может быть вытеснена. К нижней половине предъявляются требования минимального по размеру кода и минимального времени исполнения, назначение сводиться к заполнению какой либо структуры и завершению работы.
Верхняя половина уже планируется на выполнение, она обрабатывает сохранённые нижней половиной данные и может быть вытеснена в процессе обработки.
Re[13]: Вопросы на собеседовании про многопоточность
От: gangof4  
Дата: 27.05.11 20:37
Оценка:
Здравствуйте, sysenter, Вы писали:

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


G>>Каюсь, ядро 2.4. А что 2.6 вытесняемое? Дайте ссылку что-ли..


S>В той же самой книге только 3-е издание за 2005 год откройте главу 7 про планирование процессов.


Уже нашел. Да, так оно и есть еще изменения в планировщике и тд.

G>>Как я безнадежно отстал от жизни..А верхняя и нижняя это как?


S>Это архитектурное разделение драйвера на приём данных и их обработку.

S>Нижняя половина отрабатывает сразу, как поступает прерывание от устройства. Нижняя половина не может быть вытеснена. К нижней половине предъявляются требования минимального по размеру кода и минимального времени исполнения, назначение сводиться к заполнению какой либо структуры и завершению работы.
S>Верхняя половина уже планируется на выполнение, она обрабатывает сохранённые нижней половиной данные и может быть вытеснена в процессе обработки.

Ну то что в прерывании нельзя вытеснить это понятно, так всегда и было. Дальше идут bottomhalf, tasklet и тд.
Преемственность я как понимаю запрещается в спинлоках. Однако я думаю все это не должно влиять на реализацию
семафора.

Сколько всего нового можно подчерпнуть на рсдн!
Re[14]: Вопросы на собеседовании про многопоточность
От: sysenter  
Дата: 27.05.11 20:42
Оценка:
Здравствуйте, gangof4, Вы писали:

G>Преемственность я как понимаю запрещается в спинлоках. Однако я думаю все это не должно влиять на реализацию

G>семафора.

Судя по коду который я привёл IID выше, в спинлоках в цикле попытка залочить обрамлена отключением/включением вытеснения т.е. спинлок похоже может быть вытеснен в определённой точке, сразу после включения вытеснения.
Re[14]: Вопросы на собеседовании про многопоточность
От: gangof4  
Дата: 27.05.11 20:45
Оценка:
Пожалуйста, уважайте коллег и не допускайте излишнего цитирования. Для неуважающих напомню, что есть правила форума и ресурса + санкции за несоблюдение оных. Модератор
G>Сколько всего нового можно подчерпнуть на рсдн!


Однако надо помнить что одно прерывание, всегда может быть прервано другим прерыванием.
Re[15]: Вопросы на собеседовании про многопоточность
От: sysenter  
Дата: 27.05.11 20:48
Оценка:
Здравствуйте, gangof4, Вы писали:

G>Однако надо помнить что одно прерывание, всегда может быть прервано другим прерыванием.


Soft прерывание может быть вытеснено, но не hard. Собственно для софт прерываний нижняя половина и не используется, а всякие тасклеты и т.п
Re[4]: Вопросы на собеседовании про многопоточность
От: Vain Россия google.ru
Дата: 27.05.11 20:49
Оценка:
Здравствуйте, Polonius, Вы писали:

P>Все это значит, чтобы передать "валидный" хэндл в другой поток, нужно сначала сделать ему AddRef()

P>и только потом передавать в др поток (тогда можно считать, что в новом потоке "валидный" хэндл).
Нельзя, нужно дождаться чтобы и другой поток сделал AddRef.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[21]: Вопросы на собеседовании про многопоточность
От: IID Россия  
Дата: 27.05.11 20:50
Оценка:
Здравствуйте, sysenter, Вы писали:

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


IID>>Потому что так не принято. Считаются накладные расходы на ядерный вызов. Это сразу и туда, и обратно. Считать их как отдельные сущности не имеет смысла как минимум потому что они не равны друг другу по вычислительным затратам.


S>В литературе объясняется полностью весь процесс от вызова обёртки ядерного вызова, последующего вызова функции врапера которая из таблицы номеров системных вызовов извлекает адрес в кернел моде, сохранения контекста, перехода на обработчик ядерного вызова и восстановления контекста после выполнения работы. Так вот расходы на сохранение и восстановление контекста одинаковы, а время работы врапера и поиск адреса в таблице системных вызовов не настолько велико, чтобы вход в кернел мод был хотя бы в два раза дороже выхода. И заметь у меня было написано _4 переключения контекста_, а не 4 обработки ядерного вызова.


А кроме этого есть, например, валидация параметров, переданных системному вызову. При этом все параметры, переданные по указателю, копируются в память ядра. Чтобы работа с ними из супервизоровского кода была безопасной.

IID>>Сколько будет переключений в KM на каждый лок и анлок ? ты бы лучше юзермодный код привёл, чтобы сравнить затраты на переключение.


S>Будет нисколько,


Этого просто не может быть. Чтобы уснуть потоку придётся перейти в кернел-мод.

S>в КМ переключение происходит только для разрешения конфликта, а так лок/анлок происходит в юзерспейс через расшареную память где атомарно происходит изменение счётчика.


Пока синхронизация сводится только к изменению счётчика даже наивный вариант не требует перехода в режим ядра. Что насчёт предельных значений ?

S>Мне ковырять код glibc не интересно, от этого никакой пользы не будет по сравнению с кодом ядра.


Очень зря. Иначе бы ты сам убедился что переход в режим ядра будет.
kalsarikännit
Re[19]: Вопросы на собеседовании про многопоточность
От: IID Россия  
Дата: 27.05.11 20:52
Оценка:
Здравствуйте, sysenter, Вы писали:

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


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


S>Ну, не составляет,


Замечательно. Значит ты вменяем, в отличие от кучи здесь отметившихся.

S>вопрос то был в том, что реализовать в юзер мод семафор с производительностью близкой к КМ не реально. Что вы удачно и подтвердили.


Реально Про затраты на системные вызовы мы говорим выше, давай не распыляться по треду.
kalsarikännit
Re[22]: Вопросы на собеседовании про многопоточность
От: sysenter  
Дата: 27.05.11 20:56
Оценка:
Здравствуйте, IID, Вы писали:

IID>А кроме этого есть, например, валидация параметров, переданных системному вызову. При этом все параметры, переданные по указателю, копируются в память ядра. Чтобы работа с ними из супервизоровского кода была безопасной.


На счёт параметры переданные по указателю копируются память ядра не уверен, скорее всего в линухе это не так.

IID>Этого просто не может быть. Чтобы уснуть потоку придётся перейти в кернел-мод.


Ну, это беспорно.

IID>Пока синхронизация сводится только к изменению счётчика даже наивный вариант не требует перехода в режим ядра. Что насчёт предельных значений ?


Нужно смотреть код.

IID>Очень зря. Иначе бы ты сам убедился что переход в режим ядра будет.


Glibc весит не меньше ядра, в такой куче кода один раз копался, там всё не очень очевидно. Больше не хочу.
Re[16]: Все с тобой ясно
От: Олег К.  
Дата: 28.05.11 03:54
Оценка:
Ты бы хоть почитал о семафорах перед тем как постить сюда неработающего уродца.

Чтобы не быть голословным, вот пример кода на котором твой семафор завалится:
Semaphore sem;  // Создадим семафор, счетчик равен нулю

sem.Init(100);  // Проинициализируем, максимальное значение счетчика может быть 100

// Попробуем захватить наш семафор...

sem.Acquire();  // А тут уже проблема. Счетчик у нас все еще ноль, семафор
                // находится в несигнальном состоянии, acquire() должна заблокироваться,
                // но у тебя она увеличит счетчик на единицу и вернется...


В общем логика у тебя вся неправильная и семафор не работает. В Semaphore::Acquire() нужно уменьшать счетчик и в Semaphore::Release() увеличивать, а не наоборот как это сделано у тебя. И сравнения чтобы определить в сигнальном состоянии семафор или нет нужно делать относительно нуля а не относительно максимального значения.

Ну и еще, ты даешь возможность задать семафору максимальное значение. Однако ты не даешь возможности задать начальное значение счетчика, что вообще-то поважнее максимального значения. Ну и переменную m_lLockCount лучше бы назвать как-нибудь m_lInstanceCount т.к. семафор ведет счет instances какого-нибудь ресурса а не локов. Но это так, мелочи уже.

IID>

IID>#pragma once

IID>//
IID>// Наивная версия захвата/освобождения.
IID>// Максимально прозрачная.
IID>//
IID>class Semaphore
IID>{
IID>protected:
IID>    HANDLE m_hEvent;
IID>    volatile LONG m_lLockCount;
IID>    LONG m_lMaxCount;    

IID>public:
IID>    Semaphore();
IID>    ~Semaphore();

IID>    bool Init(
IID>        LONG lMaxCount
IID>        );
IID>    void Close();

IID>    bool Acquire(
IID>        DWORD dwTimeout = INFINITE
IID>        );
IID>    void Release();
IID>};

IID>Semaphore::Semaphore()
IID>    : m_hEvent(NULL)
IID>    , m_lLockCount(0)
IID>    , m_lMaxCount(0)
IID>{
IID>}

IID>Semaphore::~Semaphore()
IID>{
IID>    Close();
IID>}

IID>bool Semaphore::Init(
IID>    LONG lMaxCount
IID>    )
IID>{
IID>    ASSERT(!m_hEvent);
IID>    ASSERT(lMaxCount > 0);

IID>    if (lMaxCount <= 0)
IID>        return false;

IID>    m_lMaxCount = lMaxCount;

IID>    m_hEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
IID>    return !!m_hEvent;
IID>}

IID>void Semaphore::Close()
IID>{
IID>    if (m_hEvent)
IID>    {
IID>        ASSERT(!m_lLockCount);
IID>        CloseHandle(m_hEvent);
IID>        m_hEvent = NULL;
IID>    }
IID>}

IID>bool Semaphore::Acquire(
IID>    DWORD dwTimeout /*= INFINITE */
IID>    )
IID>{
IID>    ASSERT( m_hEvent );
IID>    if (InterlockedIncrement(&m_lLockCount) <= m_lMaxCount)
IID>        return true;

IID>    if (WAIT_OBJECT_0 == WaitForSingleObject(m_hEvent, dwTimeout))
IID>        return true;

IID>    Release();
IID>    return false;
IID>}

IID>void Semaphore::Release()
IID>{
IID>    if (InterlockedDecrement(&m_lLockCount) >= m_lMaxCount)
IID>        return;

IID>    SetEvent(m_hEvent);
IID>}

IID>//
IID>// Версия захвата/освобождения, минимизирующая переключение в KM.
IID>//
IID>class SemaphoreSMP : public Semaphore
IID>{
IID>    LONG m_lWaitersCount;

IID>public:
IID>    SemaphoreSMP() : m_lWaitersCount(0) {}

IID>    bool Acquire(
IID>        DWORD dwTimeout = INFINITE
IID>        );
IID>    void Release();
IID>};

IID>bool SemaphoreSMP::Acquire(
IID>    DWORD dwTimeout /*= INFINITE */
IID>    )
IID>{
IID>    ASSERT( m_hEvent );
IID>    if (InterlockedIncrement(&m_lLockCount) <= m_lMaxCount)
IID>        return true;

IID>    int iSemSpinCount = 300;
IID>    for(int i = 0; i < iSemSpinCount; i++)
IID>    {
IID>        if (InterlockedCompareExchange(&m_lLockCount, m_lMaxCount, m_lMaxCount) == m_lMaxCount)
IID>            return true;
IID>    }

IID>    InterlockedIncrement(&m_lWaitersCount);
IID>    DWORD dwWaitResult = WaitForSingleObject(m_hEvent, dwTimeout);
IID>    if (WAIT_OBJECT_0 == dwWaitResult)
IID>        return true;

IID>    InterlockedDecrement(&m_lWaitersCount);
IID>    InterlockedDecrement(&m_lLockCount);
IID>    return false;
IID>}

IID>void SemaphoreSMP::Release()
IID>{
IID>    if (InterlockedDecrement(&m_lLockCount) >= m_lMaxCount)
IID>        return;

IID>    if (InterlockedDecrement(&m_lWaitersCount) >= 0)
IID>    {
IID>        SetEvent(m_hEvent);
IID>    } else {
IID>        InterlockedIncrement(&m_lWaitersCount);
IID>    }
IID>}

IID>
Re[18]: Вопросы на собеседовании про многопоточность
От: Олег К.  
Дата: 28.05.11 04:12
Оценка:
S>>Про код, бегло посмотрел, работать похоже будет.

Код абсолютно нерабочий.

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


Вот смотри. У тебя было время почитать документацию, посидеть над кодом. И то ты привел здесь абсолютно неправильный код. Что уж говорить о собеседующихся которые находятся в более стрессовом состоянии? Зато понтов-то
Re[10]: Вопросы на собеседовании про многопоточность
От: Олег К.  
Дата: 28.05.11 04:25
Оценка:
IID>>>Более того, "скорее всего" означает кучу говнокода, который на первый взгляд корректен,

ОК>>Этот твой user-space semaphore и есть самый что ни на есть гавнистый говнокод, как бы аккуратно его не написали. А ты даже и не понимаешь этого.



S>Как тестовый вопрос задание про semaphore на тему многопоточность очень даже хорошо. По крайней мере придется вспомнить что такое Event, как обновлять lock-счетчик. Видно как мысли кандидат. Кода в пределах 100-200 строк, которые можно даже на доске писать, и не скажешь, что используют кандидата, чтобы писать продакшен код.


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

И на данный момент чувак толкавший это в качестве "задачки для интервью" сам ее же и завалил хотя у самого было время посидеть над ней.
Re[3]: Вопросы на собеседовании про многопоточность
От: Олег К.  
Дата: 28.05.11 04:36
Оценка:
IID>>Я любил давать кандидатам задачку на реализацию семафора "вручную". При условии что остальные объекты синхронизации (ивенты, мьютексы и т.д.) у них есть. Казалось бы, но результат удивлял. Мало кто мог реализовать сразу и без ошибок. Многие не могли найти ошибку и/или исправить, когда на неё показывал пальцем.

KP>Честно сказать, не понял чем эта задача хуже "8 гномиков встали раком"


Это идиотизм.

KP>либо переверните однонаправленный список или любая другая задача ни о чем.


А вот это я считаю нормально. Сам бы давать не стал но и нос от нее не ворочал. У развернуть списка хотя бы есть практическая ценность. Другое дело что в реальном коде ее писать не будут т.к. уже есть имплементации, но вот делать семафор в юзер спейсе — у нее нет никакой практической ценности.

KP>Даже удивительно что народ столько возмущается, неужели написание такой простой херотени доставляет какие-то трудности?


Ну, данный товарищ сам же ее и завалил, хотя у него было время над ней посидеть. Так что не все так просто, особенно учитывая последнии тенденции на интервью. Плюс не забывай что интервью могут проводить полнейшие дурачки которые доведут любую здравую идею до абсурда.
Re[3]: Вопросы на собеседовании про многопоточность
От: Олег К.  
Дата: 28.05.11 04:38
Оценка: +1 -1
IID>>Я любил давать кандидатам задачку на реализацию семафора "вручную". При условии что остальные объекты синхронизации (ивенты, мьютексы и т.д.) у них есть. Казалось бы, но результат удивлял. Мало кто мог реализовать сразу и без ошибок. Многие не могли найти ошибку и/или исправить, когда на неё показывал пальцем.

O>Стало любопытно. Итого — десять минут на реализацию, плюс еще минут пятнадцать на

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

O>P.S. Гуру по многопоточности себя не считаю. Просто удивляюсь реакции.


Очередная распальцовка?
Re[4]: Вопросы на собеседовании про многопоточность
От: Олег К.  
Дата: 28.05.11 04:40
Оценка:
ПМ>Когда вы в последний раз реализовывали мьютекс/сигнал/эвент?

ПМ>Тут товарищь писал, что большая часть собеседуемых не может нормально написать семафор,


Жжошь, чувак!
Re[2]: Вопросы на собеседовании про многопоточность
От: Олег К.  
Дата: 28.05.11 04:47
Оценка:
ST>В одном чудном месте меня попросили написать реализацию семафора через мьютекс

+100 но не потому что считаю что нужно давать такие задачи на интервью, а потому что вижу что человек понимает идиотизм данной задачи.
Re[3]: Вопросы на собеседовании про многопоточность
От: sysenter  
Дата: 28.05.11 05:02
Оценка:
Здравствуйте, Олег К., Вы писали:

ОК>+100 но не потому что считаю что нужно давать такие задачи на интервью, а потому что вижу что человек понимает идиотизм данной задачи.


Задача на самом деле интересная, я бы добавил к задаче ещё и вопросы про то почему не стоит реализовывать семафор в юзерспейс, какие накладные расходы будут.
Идиотизм, как вы говорите, в самом принципе реализовывать семафор в юзерспейс через примитивы синхронизации ядра. И задача не для собеседования где хотят проверить владение многопоточностью, а как разминка для ума очень даже не плоха.
Re[3]: Вопросы на собеседовании про многопоточность
От: Олег К.  
Дата: 28.05.11 05:11
Оценка: +1 -2
ST>>В одном чудном месте меня попросили написать реализацию семафора через мьютекс

Тех кто дает именно эту задачу надо избивать бейсбольными битами.

S>И как, вы справились, как делали? Что сказал просивший про код?


По вопросу можно оценить уровень спрашивающего и если он дает такое гуано на интервью, то как специалист он ничто.

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

В общем s.ts привел пример задачи, но условие привел не до конца. Нужно реализовать семафор используя только built-in типы и только mutex-ы. Это первая часть условия. Вторую часть я пока не буду говорить. Попробуй для начала сделать как обычный спинлок. Это просто. Затем уже как настоящий семафор который не потребляет CPU time. Это уже сложнее и для этого нужна вторая часть условия которая вообще сделает задачу еще более абсурдной.

P.S. Вторую часть не говорю пока что потому что к ней надо "прийти" в ходе интервью.
P.P.S. Подчеркну что я категорических против таких задач но к ним надо быть готовым т.к. дураков везде много а они, как говорится, изобретательны.
Re[13]: Вопросы на собеседовании про многопоточность
От: sysenter  
Дата: 28.05.11 05:18
Оценка:
Здравствуйте, sysenter, Вы писали:

S>Происки завистников)


Особенно в свете этого. Так, что на спинлоки из Linux бочку катить не нужно))
ядро Linux на 1024 процессоров спокойно параллелится, а винда только на 256.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.