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

SD>По-человечески вытесняемое оно становится только с RT_PREEMPT patch. Это отдельное ядро, и у SuSE (Novell) оно вообще идет как отдельный Add-On продукт к своему SLES'у. Код ядра там достаточно сильно изменен (патч большой), как раз в тех местах, где синхронизация. В силу специфики моей нынешней работы там приходится периодически копаться (нам нужен soft realtime, а без вытеснения ядра это невозможно в принципе).

Вообще-то Linux, что называется из коробки удовлетворяет требованиям soft realtime, а патч про который вы говорите нужен для реализации hard realtime в ядре. Здесь.

S>Вообще-то Linux, что называется из коробки удовлетворяет требованиям soft realtime, а патч про который вы говорите нужен для реализации hard realtime в ядре. Здесь.

Терминами мы можем играть сколько угодно (есть разброд и шатания в области того, что считать soft realtime — но то, что в mainstream kernel, очень странный soft RT, разброс setitimer'а влёгкую составляет микросекунды — проверено многократно).
Но вот факт: вытеснение ядра без этого патча очень, что называется, ограничено.
hard realtime не достигается даже с этим патчем (увы), хотя с нужными железками от IBM для несерьезного применения (т.е. не АЭС) уже катит (в частности, для "начинающих" финансовых товарищей, которые еще не пилят свои чипы).

В любом случае, я писал немножко о другом: слухи о вытесняемости ядра Linux (давайте не путать всякий около-ядерный хлам в виде bottom half'ов разных драйверов с собственно ядром) слегка преувеличены.

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

SD>Терминами мы можем играть сколько угодно (есть разброд и шатания в области того, что считать soft realtime — но то, что в mainstream kernel, очень странный soft RT, разброс setitimer'а влёгкую составляет микросекунды — проверено многократно).

Это как раз и есть софт риалтайм, вообще погрешность равна HZ*0.5 т.е. при HZ = 1000 имеет погрешность до 1.5 миллисекунд.

SD>Но вот факт: вытеснение ядра без этого патча очень, что называется, ограничено.

А можно по конкретнее где именно ограничено, чтобы я в исходниках посмотрел?

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

Может
SD>Кстати, подумалось, что есть хороший вопрос на внимательность для собеседования:
SD>

SD>class RefCountable
SD>{
SD>  Mutex m;
SD>  int ref_counter;
SD>  void Release()
SD>  {
SD>    m.lock();
SD>    --ref_counter;
SD>    if (ref_counter == 0) delete this;
SD>    m.unlock();
SD>  }
SD>

SD>Требуется исправить код (сразу предупрежу, я не компилировал и не проверял синтаксическую правильность — это код для иллюстрации).

Может так:

class RefCountable
{
  struct auto_lock
    { 
     Mutex &mRef;
     auto_lock(Mutex &m) : mRef(m) { mRef.lock(); }
     ~auto_lock() { mRef.unlock(); }
    }

  Mutex m;
  int ref_counter;
  int increment()
  {
   auto_lock al(m);
   return ++ref_counter;
  }
  int decrement()
  {
   auto_lock al(m);
   return --ref_counter;
  }

  void Release()
  {
   if (!decrement()) delete this;
  }

Здравствуйте, Олег К., Вы писали:
ОК>Реализовать семафор в кернел моде намного проще и понятнее этого изврата который ты хочешь увидеть в юзер моде при помощи других примитивов.
Модельный семафор от IID будет примерно таким же, как честный кернелмодовский; только последний — это ~ спинлок, счетчик и очередь, а для первого — нужно будет на замену подобрать юзермодные примитивы синхронизации.

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

Дело было так...

Что, спрашивают, приходилось делать про многопоточность.
Ну, я вспомнил, что пришлось как-то сделать семафор на спинлоках, т.к. стандартный тормозил — не подходил под задачу.
Ну и отлично, говорят. Давайте тогда напишите нам на бумажке семафор с помощью, ну, к примеру, мьютексов.
Уверены, говорю, м.быть лучше через спин-локи какие-нибудь ?
Нет, говорят, давай через мьютексы.
Объясняю, что через мьютекс не получится, т.к. его нельзя разлочить из другого потока.
А семафор — можно, потому одно через другое не выражается.
С точки зрения использования это и есть большая разница между "семафором со счетчиком 1" и "мьютексом".
Будет неопределенное поведение (линукс или венда) или определенная ошибка (.net какой-нибудь).
Чувак завис.
Странные, мол, вещи говорите.
А как же, спрашивает, у нас-то это работает ?

В итоге выяснилось, что у них там всего 2 потока.
А в 2-х потоках, понятно, не может быть ситуации разлочки мьютекса из другого треда.
Ну, чисто логически. Если там диаграмму состояний нарисовать или код написать, то сразу это дело ясно.

Я к чему.
Вот такие у людей семафоры понаписаны, кторые только в 2-х потоках работают.
При чем, явно, там кто-то написал его, назвал семафором.
А мужики-то [коллеги] и не знают. И не заглянув в реализацию так и не узнают что там за семафор, пока не начнет все это их дело падать раз в 3 месяца с дребезгом по непонятной причине.
Что интересно, эти же люди спрашивают на собеседованиях.
Не удивлюсь, если и статьи на эту тему пишут, аль книжки.
Ну или влюбимом бложеге отжигают — это уж как минимум.
Жесть, в общем.


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

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

ST>>В одном чудном месте меня попросили написать реализацию семафора через мьютекс

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

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

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

Как на такие вопросы можно ответить правильно если что стоит за "примитивами синхронизации ядра" или как работает планировщик никто в деталях, кроме MS, не знает? Все что пишут в книжках — общие слова, но не код. Исходный код был бы единственной точной инфой, а так все это "second hands".

Какой смысл вообще задавать такие вопросы где решение и ответ неоднозначны?

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

S>Как на такие вопросы можно ответить правильно если что стоит за "примитивами синхронизации ядра" или как работает планировщик никто в деталях, кроме MS, не знает? Все что пишут в книжках — общие слова, но не код. Исходный код был бы единственной точной инфой, а так все это "second hands".

Есть исходный код NT и возможно в том исходном коде, что гуляет по сети от w2k тоже есть реализация семафора. Да и потом, зачем на винде сосредотачиваться?

ST>Что, спрашивают, приходилось делать про многопоточность.
ST>Ну, я вспомнил, что пришлось как-то сделать семафор на спинлоках, т.к. стандартный тормозил — не подходил под задачу.

Жесть.

ST>Ну и отлично, говорят. Давайте тогда напишите нам на бумажке семафор с помощью, ну, к примеру, мьютексов.
ST>Уверены, говорю, м.быть лучше через спин-локи какие-нибудь ?
ST>Нет, говорят, давай через мьютексы.
ST>Объясняю, что через мьютекс не получится, т.к. его нельзя разлочить из другого потока.
ST>А семафор — можно, потому одно через другое не выражается.
ST>С точки зрения использования это и есть большая разница между "семафором со счетчиком 1" и "мьютексом".

+1.

ST>Будет неопределенное поведение (линукс или венда) или определенная ошибка (.net какой-нибудь).
ST>Чувак завис.
ST>Странные, мол, вещи говорите.

Ага, бывают такие дурачки.

ST>А как же, спрашивает, у нас-то это работает ?

ST>В итоге выяснилось, что у них там всего 2 потока.
ST>А в 2-х потоках, понятно, не может быть ситуации разлочки мьютекса из другого треда.
ST>Ну, чисто логически. Если там диаграмму состояний нарисовать или код написать, то сразу это дело ясно.

Ну а вообще хоть с ним(и) поговорить можно было? А то все что у меня были на предложение воспользоваться компилятором и/или проверить в MSDN Library уходили в отказ. Говорили что типа сам можешь после интервью проверить свои знания.

Ну и какой вообще результат этого интервью был?

ST>Я к чему.
ST>Вот такие у людей семафоры понаписаны, кторые только в 2-х потоках работают.
ST>При чем, явно, там кто-то написал его, назвал семафором.
ST>А мужики-то [коллеги] и не знают. И не заглянув в реализацию так и не узнают что там за семафор, пока не начнет все это их дело падать раз в 3 месяца с дребезгом по непонятной причине.
ST>Что интересно, эти же люди спрашивают на собеседованиях.
ST>Не удивлюсь, если и статьи на эту тему пишут, аль книжки.
ST>Ну или влюбимом бложеге отжигают — это уж как минимум.
ST>Жесть, в общем.

Действительно жесть. И таких ой как много бывает на интервью. И дело даже не в многопоточности.

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

S>Как на такие вопросы можно ответить правильно если что стоит за "примитивами синхронизации ядра" или как работает планировщик никто в деталях, кроме MS, не знает? Все что пишут в книжках — общие слова, но не код. Исходный код был бы единственной точной инфой, а так все это "second hands".

Вообще-то нормальные интервьюеры спрашивают о понятиях, а они везде одинаковы.

S>Какой смысл вообще задавать такие вопросы где решение и ответ неоднозначны?

Здравствуйте, Олег К., Вы писали:

ОК>Вообще-то нормальные интервьюеры спрашивают о понятиях, а они везде одинаковы.

так и запишем — нормальные интервьюеры базарят по понятиям

Здравствуйте, IID, Вы писали:
A>>В винде внутри процесса можно CriticalSection использовать, а между процессами Messaging, разве нет ?
IID>Между процессами можно использовать любые объекты ядра, имеющие описатель в User land и поддерживающие синхронизацию: Synchronization Objects. Второй процесс получит их либо открыв по имени, либо в результате дупликации описателей процессом-владельцем.
...либо унаследовав от процесса-родителя. Бывает и такое.