1. Если вы только начинаете программировать на ассемблере и не знаете с чего начать, тогда попробуйте среду разработки ASM Visual IDE
    (c) на правах рекламы
    Скрыть объявление

Ядро - повторно входимо?

Тема в разделе "WASM.NT.KERNEL", создана пользователем ers, 20 июн 2010.

  1. ers

    ers New Member

    Публикаций:
    0
    Регистрация:
    21 май 2010
    Сообщения:
    3
    Прочитал в статье, соответствующей курсу лекций одного технического ВУЗа, высказывание следующего содержания:
    Я хотел бы прояснить для себя данное утверждение, уточнить - верно оно или нет, а если да - как со стороны операционной системы обеспечивается неповторновходимость?
    Если код выполняется в режиме ядра на уровне PASSIVE_LEVEL - он может быть прерван. Если после этого в результате передиспетчеризации начнет выполняться другой поток, находившийся в режиме пользователя, он ведь продолжит выполнение в режиме пользователя? Тогда он может войти в режим ядра => повторновходимость? Или при выполнении в режиме ядра, поток не может быть прерван для выполнения кода в режиме пользователя? Что в этом случае следует понимать под "правами на контекст ядра"?
     
  2. slesh

    slesh New Member

    Публикаций:
    0
    Регистрация:
    6 фев 2009
    Сообщения:
    214
    Возможно автор имеет ввиду чуть другое. Когда ты делаешь sysenter ты попадаешь в Kernel Mode но не контекст ядра. Даже в ядре ты остаешься в контексте процесса который вызвал код.
    Другое дело - когда загружаешь драйвер. Тогда ты попадаешь в контекст ядра.

    Тогда хз каким образом пашут потоки ядра
     
  3. katrus

    katrus New Member

    Публикаций:
    0
    Регистрация:
    7 мар 2007
    Сообщения:
    612
    В принципе это утверждение верно... Но для старых версий Linux. Там ядро было non-reentrant. Есть предположение, что автор статьи не понимает о чем пишет.
     
  4. wasm_test

    wasm_test wasm test user

    Публикаций:
    0
    Регистрация:
    24 ноя 2006
    Сообщения:
    5.582
    Судя по терминам. речь про НТ. Там ядро переключаемо. Любой поток, выполняющийся на процессоре с IRQL <= APC_LEVEL.
    конечно
    да. для синхронизации используются спин-блокировки.
    автор курил))
     
  5. artyom

    artyom New Member

    Публикаций:
    0
    Регистрация:
    17 дек 2008
    Сообщения:
    2
    Забавно, "Ядро не повторновходимо". Речь о реентерабельности кода, как я понимаю. Другими словами, может ли один и тот же код в ntoskrnl выполняться в нескольких потоках одновременно и не будет ли при этом возникать рассинхронизации. Кончено может выполняться. К сожалению, наши ВУЗы имеют весьма скромное представление об NT.
     
  6. Clerk

    Clerk Забанен

    Публикаций:
    0
    Регистрация:
    4 янв 2008
    Сообщения:
    6.689
    Адрес:
    РБ, Могилёв
    Повторно входимо. Из трап-фреймов цепочки формируются. Как пример - механизм теневых калбэков. Специально для этого введено понятие базового трап-фрейма, это тот который самый первый. Далее цепочка может формироваться по разным причинам - это прерывания, либо програмные механизмы.
     
  7. Sol_Ksacap

    Sol_Ksacap Миша

    Публикаций:
    0
    Регистрация:
    6 мар 2008
    Сообщения:
    623
    А вот теневые колбеки – это, как нам кажется, не совсем удачный пример. Потому что ядерная часть древней графической подсистемы винды как раз НЕ реентерабельна.
    Захотелось сделать окошко видимым? Вызываем ShowWindow() и попадаем в ядро на NtUserShowWindow(), где эксклюзивно захватывается сессионно глобальный лок. Другому потоку, совершенно не связанному с первым, нужно в этот момент, скажем, удалить пункт меню? Он вызывает DeleteMenu() и оказывается в ядре на NtUserDeleteMenu(), где вынужден ждать, пока сессионный лок освободится. Первому потоку, выполняемому в ядре, понадобилось сделать колбек в юзермод? Отлично, на время выполнения юзермодного кода лок освобождается – но по возращению в ядро нужно будет снова его захватить. Т.е. в этом плане получаем именно нереентерабельную систему. (Иначе при этой кодобазе, берущей начало ещё в Win16, поступать попросту невозможно).
    Но, конечно, в ntoskrnl – как уже сказали – такого чудовищного по современным меркам механизма не применяется.
     
  8. Clerk

    Clerk Забанен

    Публикаций:
    0
    Регистрация:
    4 янв 2008
    Сообщения:
    6.689
    Адрес:
    РБ, Могилёв
    Sol_Ksacap
    Пример удачный. Например понижаете в IRQL до нулевого и размаскируете прерывания, состояние задачи уже сохранено, тогда при приходе железячного прерывания вновь текущее состояние задачи сохраняется, после отработки ISR задача будет возобновлена. Иначе был бы не возможным вложенный трап-процессинг.
     
  9. Clerk

    Clerk Забанен

    Публикаций:
    0
    Регистрация:
    4 янв 2008
    Сообщения:
    6.689
    Адрес:
    РБ, Могилёв
    Кстате очень многим не понятны конструкции типа такой:
    Код (Text):
    1. TrapFrame = (PKTRAP_FRAME)((PUCHAR)Thread->InitialStack -
    2.                 ALIGN_UP(sizeof(KTRAP_FRAME),KTRAP_FRAME_ALIGN) -
    3.                 sizeof(FX_SAVE_AREA));
    Изза возможной вложенности задач всегда используется первый её контекст, лежащий на дне ядерного стека.
     
  10. Clerk

    Clerk Забанен

    Публикаций:
    0
    Регистрация:
    4 янв 2008
    Сообщения:
    6.689
    Адрес:
    РБ, Могилёв
    Sol_Ksacap
    В ISR возникает #AV к примеру. Что произойдёт ?