На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
Обратите внимание:
1. Прежде чем начать новую тему или отправить сообщение, убедитесь, что вы не нарушаете правил форума!
2. Обязательно воспользуйтесь поиском. Возможно, Ваш вопрос уже обсуждали. Полезные ссылки приведены ниже.
3. Темы с просьбой выполнить какую-либо работу за автора в этом разделе не обсуждаются.
4. Используйте теги [ code=cpp ] ...текст программы... [ /code ] для выделения текста программы подсветкой.
5. Помните, здесь телепатов нет. Старайтесь формулировать свой вопрос максимально грамотно и чётко: Как правильно задавать вопросы
6. Запрещено отвечать в темы месячной и более давности без веских на то причин.

Полезные ссылки:
user posted image FAQ Сайта (C++) user posted image FAQ Форума user posted image Наши Исходники user posted image Поиск по Разделу user posted image MSDN Library Online (Windows Driver Kit) user posted image Google

Ваше мнение о модераторах: user posted image B.V.
Модераторы: B.V.
  
> KeWaitForSingleObject()
    Для синхронизации доступа к списку используется вот такое:

    ExpandedWrap disabled
      VOID FooLock()
      {
          NTSTATUS Status = STATUS_SUCCESS;
       
          PAGED_CODE();
       
          do
          {
              Status = KeWaitForSingleObject(&FooMutex, Executive, KernelMode, FALSE, NULL);
       
          } while (Status == STATUS_ALERTED);
      }
       
      VOID FooUnlock()
      {
          PAGED_CODE();
       
          KeReleaseMutex(&FooMutex, FALSE);
      }


    И работало всё это уже 12 лет, но вот начались сыпаться BSODы у кастомера о том, что список испорчен. Пока есть только минидамп, в нём нельзя понять захвачен ли мьютекс. Может ли KeWaitForSingleObject() вернуть какой-то статус типа STATUS_KERNEL_APC или иной и не захватить мьютекс?
      Теоретически нет, судя по параметрам. Другое дело, что я бы проверил IRQL. На уровнях вне DISPATCH_LEVEL объекты синхронизации не работают.
        Спасибо за ответ. Нет, IRQL <= APC_LEVEL
          Если точно не IRQL, тогда остаётся только отлаживаться. Можно завести std::atomic_bool, который выставлять после захвата/освобождения и чекать его перед.

          P.S. Теоретически в программе может быть баг, связанный с неверной синхронизацией. Часто встречающаяся ошибка – захват объекта только при изменении общего ресурса и неиспользование захвата при только чтении.
            atomic_bool не надо, в дампе памяти ядра будет видно захвачен мьютекс или нет, но дампа пока тоже нет)
            Неверную синхронизацию перепроверил - там всё гут. Если бы не было гут, то за 12 лет эта проблема бы очень часто давала бы о себе знать.

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

            ExpandedWrap disabled
              VOID FooLock()
              {
                  NTSTATUS Status = STATUS_SUCCESS;
               
                  PAGED_CODE();
               
                  do
                  {
                      Status = KeWaitForSingleObject(&FooMutex, Executive, KernelMode, FALSE, NULL);
               
                  } while (Status != STATUS_SUCCESS);
              }


            Так или иначе ответ на исходный вопрос получен, спасибо.
              В такой редакции можно попасть на дидлук. Если – из-за кривых поинтеров, например, или неверной последовательности деинициализации – мьютекс перестанет существовать.
              1 пользователей читают эту тему (1 гостей и 0 скрытых пользователей)
              0 пользователей:


              Рейтинг@Mail.ru
              [ Script execution time: 0,0266 ]   [ 15 queries used ]   [ Generated: 14.05.24, 22:49 GMT ]