У меня есть объект, который поддерживает список;один из вспомогательных методов должен
- заблокировать список
- найти первый элемент
- разблокировать список
- уведомить другой поток, чтобы начатьоперация очистки
- ожидание завершения другого потока
- повторять это до тех пор, пока список не станет пустым.
Операция очистки удаляет объект из списка из другогопоток, таким образом, он должен заблокировать список между ними.
Это работает нормально, если помощник не вызывается с блокировкой в списке, которая уже удерживается, так как операция разблокировки фактически не позволит другому потокудоступ к списку, поэтому я хотел бы отметить ошибку в этом случае.
Насколько я понял, API CRITICAL_SECTION
не предоставляет официально поддерживаемый способ запроса, удерживает ли текущий процессэтот объект, поэтому я рассматриваю подходы "взлома" (в конце концов, это средство отладки и не предназначено для ввода в производственный код):
Вариант 1 - проверка поля OwningThread
поляCRITICAL_SECTION
структура, но мне интересно, есть ли гарантия, что это поле
- всегда содержит идентификатор потока из того же числа, что и
GetCurrentThreadId()
результаты - всегда обновляются при любомпоток получает блокировку
- всегда очищается, когда мой собственный поток снимает блокировку
Вариант 2 заключается в блокировке CRITICAL_SECTION
, а затем проверяет RecursionCount
;это предполагает, что счетчик рекурсии имеет фиксированное начальное значение.
Есть ли что-то, что я пропустил, что я мог бы использовать для создания некоторого будущего (то есть, он будет шумно ломаться в строке кода, котораярядом с комментариями, где я все это объясняю) утверждение о том, что текущий поток не является держателем определенного CRITICAL_SECTION
?