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

S>У меня была уверенность, что ядро полностью вытесняемое включая и кернел мод, нужно будет перепроверить.

Полностью вытесняемое.

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

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

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

Недовольство ядерными спинлоками. Юзермодные спинлоки прекрасно вытесняются, в отличие от.

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

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

Переключения контекста будут не всегда, а только если не удалось захватить владение сразу. Будет не более одного переключения при захвате, и не более одного при освобождении. Как ты 4 насчитал ? Туда-обратно что ли считаешь ?

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

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

IID>Недовольство ядерными спинлоками. Юзермодные спинлоки прекрасно вытесняются, в отличие от.

Ядерные тоже вполне себе вытесняются. Вот кусок из реализации спинлока:

void __lockfunc __raw_##op##_lock(locktype##_t *lock)            \
{                                    \
    for (;;) {                            \
        preempt_disable();                    \
        if (likely(do_raw_##op##_trylock(lock)))        \
            break;                        \
        preempt_enable();                    \
                                    \
        if (!(lock)->break_lock)                \
            (lock)->break_lock = 1;                \
        while (!raw_##op##_can_lock(lock) && (lock)->break_lock)\
            arch_##op##_relax(&lock->raw_lock);        \
    }                                \
    (lock)->break_lock = 0;                        \
}

Только выделенное не вытесняется, остальная часть цикла спокойна может быть вытеснена.

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

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

L>>>Твой светофор — это не примитивная задача, а кусок бессмысленного говнокода.

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

L>Код в студию тогда.

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

L>>>Чтобы разбираться в многопоточности, нужно:
L>>>1. Знать, зачем, когда и почему необходимо иметь много потоков.
L>>>2. Знать, какие грабли из этого отрастают как их избегать.

IID>>Если не можешь осилить семафор, то п2 сфейлен.

L>Ты либо чего-то не договариваешь, либо сам в MT-вопросах плаваешь конкретно.

Ты точно адекватен ? Реплики как будто сгенерированы ботом.

L>>>Все.
L>>>Ниасилившие эти две проблемы занмаются конструированием велосипедов.

IID>>Да причём тут велосипед. Ты читать умеешь ? Зто задача для собеседования. А не код в production.

L>При том, что это велосипед.

Задам вопрос, уже звучавший в этой ветке: а ты на собеседованиях только нетленки ваяешь ?

L>Вам сотрудник нужен код в продакшен писать или задачи для собесебований решать? Или, как тут уже неоднократно предположили, у вас продакшен из велосипедов и состоит?

Если кандидат не может написать без багов примитивный многопоточный алгоритм то его на пушечный выстрел нельзя к MT продакшену подпускать.

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

S>У меня была уверенность, что ядро полностью вытесняемое включая и кернел мод, нужно будет перепроверить.

В NT так и есть. В буханке очень не уверен, слишком она костыльная.

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

IID>Как ты 4 насчитал ? Туда-обратно что ли считаешь ?

Именно так и считаю, разве это не соответствует тому, что происходит? А раз именно так и происходит — контекст сохраняется, выполняется вход в кернел мод, работа, восстанавливается контекст, выход в юзер спейс. Почему я должен считать иначе?

IID>А теперь возьмём ядерный семафор. В Win будет строго переключение контекста и захвате и при освобождении. Про позикс не скажу, ты показывай, а мы посмотрим.

Posix это юзерспейс библиотека основанная на ядерных фьютексах. Я же приводил код симафора из ядра.

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

IID>В NT так и есть. В буханке очень не уверен, слишком она костыльная.

Что еcть буханка?

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


S>

S>        if (likely(do_raw_##op##_trylock(lock)))        \
S>            break;                        \
S>

Разверни внутренности вот этих вызовов. Нет сорцов буханки под рукой, а гуглить лень.

Поясню свою мысль про спинлоки. В Win ядерные спинлоки, как примитив синхронизации, юзаются на уровне софтовых прерываний >= уровню планировщика (DISPATCH_LEVEL). Соответственно, на этом уровне объектами синхронизаии пользоваться нельзя. Т.к. поток никогда не будет перепланирован. Единственное, что может прервать код, захвативший спинлок, это прерывание не ниже аппаратного. Поэтому, увидев ожидание внутри спинлока я логично предположил, что вместо ожидания с помощью планировщика имеет место быть тупой цикл.

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

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

G>>Иначе как заблокироваться-то. В режиме ядра то многозадачность не вытесняющая.

S>У меня была уверенность, что ядро полностью вытесняемое включая и кернел мод, нужно будет перепроверить.

Я говорю про Linux..Цитирую O'Reilly Undestanding Linux Kernel:

11.2.1 Nonpreemptability of Processes in Kernel Mode
As already pointed out, the Linux kernel is not preemptive, that is, a running process cannot
be preempted (replaced by a higher-priority process) while it remains in Kernel Mode. In
particular, the following assertions always hold in Linux:
• No process running in Kernel Mode may be replaced by another process, except when
the former voluntarily relinquishes control of the CPU.[1]
[1] Of course, all context switches are performed in Kernel Mode. However, a context switch may occur only when the current process is going to
return in User Mode.
• Interrupt or exception handling can interrupt a process running in Kernel Mode;
however, when the interrupt handler terminates, the kernel control path of the process
is resumed.
• A kernel control path performing interrupt or exception handling can be interrupted
only by another control path performing interrupt or exception handling.

G>>Прерывания от PIT по кванту времени правда тоже вызывают schedule, но насколько я помню если проц. застрял в kernel mode

S>Что-то как-то сомнительно.

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

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

IID>Разверни внутренности вот этих вызовов. Нет сорцов буханки под рукой, а гуглить лень.

Сводиться к вызову

# define arch_spin_trylock(lock)    ({ (void)(lock); 1; })

где lock есть что-то архитектурно зависимое типа ассемблерного префикса lock из x86, дальше ковырять лень.

IID>Поясню свою мысль про спинлоки. В Win ядерные спинлоки, как примитив синхронизации, юзаются на уровне софтовых прерываний >= уровню планировщика (DISPATCH_LEVEL). Соответственно, на этом уровне объектами синхронизаии пользоваться нельзя. Т.к. поток никогда не будет перепланирован. Единственное, что может прервать код, захвативший спинлок, это прерывание не ниже аппаратного. Поэтому, увидев ожидание внутри спинлока я логично предположил, что вместо ожидания с помощью планировщика имеет место быть тупой цикл.

Имеет место тупой цикл, который может быть вытеснен в определённой точке.

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

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

IID>>Как ты 4 насчитал ? Туда-обратно что ли считаешь ?

S>Именно так и считаю, разве это не соответствует тому, что происходит? А раз именно так и происходит — контекст сохраняется, выполняется вход в кернел мод, работа, восстанавливается контекст, выход в юзер спейс. Почему я должен считать иначе?

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

IID>>А теперь возьмём ядерный семафор. В Win будет строго переключение контекста и захвате и при освобождении. Про позикс не скажу, ты показывай, а мы посмотрим.

S>Posix это юзерспейс библиотека основанная на ядерных фьютексах. Я же приводил код симафора из ядра.

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

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

S>Что еcть буханка?

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

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

Буханка, такая буханка Я тоже помню потоки ругани про однозадачное буханочное ядро от знакомого рисёчера.

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

S>Про код, бегло посмотрел, работать похоже будет.

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

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

G>Я говорю про Linux..Цитирую O'Reilly Undestanding Linux Kernel:

Это про какую версию ядра 2.6 или 2.4? Книгу какого года издания читаете?
Ядро Linux вытесняемое и потоки ядра также могут вытеснены, это 100% информация.

G>Вот как..Ну во всяком случае если драйвер линуха в кернел моде зациклить, то ничего уже не работает.

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

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

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

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

IID>Буханка, такая буханка Я тоже помню потоки ругани про однозадачное буханочное ядро от знакомого рисёчера.

Ну вообще с невытесняемым ядром на мой взгляд трудности некоторые отпадают..Однако для SMP уже конечно
все не так хорошо.

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

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

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

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

G>>Я говорю про Linux..Цитирую O'Reilly Undestanding Linux Kernel:

S>Это про какую версию ядра 2.6 или 2.4? Книгу какого года издания читаете?
S>Ядро Linux вытесняемое и потоки ядра также могут вытеснены, это 100% информация.

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

G>>Вот как..Ну во всяком случае если драйвер линуха в кернел моде зациклить, то ничего уже не работает.

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

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

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

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

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

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

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