Что может пойти не так, если вы освободите SRWLock из потока, отличного от того, который его получил?
Клиент обнаружил, что если он запускал свою программу в Application Verifier, инструмент определял, что его программа получала блокировку SRWLock в монопольном режиме в одном потоке, но освобождала ее в другом потоке. В документации нашли примечание:
Спросили, что пойдет не так, если нарушить это правило, потому что в документации об этом не сказано.
В документации не сказано, что пойдет не так, потому что операция не поддерживается, поэтому поведение не определено. Вам не нужно определять неопределенное поведение.
Тем не менее, один из членов команды ядра объяснил, что пошло не так.
Система отслеживает, какой поток получил блокировку SRWLock, чтобы иметь возможность работать со сценариями инверсии приоритета: если поток с низким приоритетом получает блокировку SRWLock, а поток с более высоким приоритетом блокируется в ожидании получения блокировки SRWLock, поток переносится в поток-владелец.
Эта информация, помогающая избежать инверсии приоритетов, хранится в предварительно выделенных данных для каждого потока.
Если вы освободите SRWLock из потока, отличного от того, который его захватил, то внутренняя бухгалтерия испортится. Наиболее вероятным результатом является то, что передача приоритета получающему потоку никогда не удаляется (поскольку он был очищен не тем потоком). С точки зрения стороннего наблюдателя, это выглядит так, будто приоритет приобретающего потока постоянно повышался без какой-либо причины.
Разработчики ядра не сказали, но я подозреваю, что еще одним последствием является то, что любая передача приоритета освобождающему потоку удаляется преждевременно, поэтому похоже, что приоритет освобождающего потока был понижен без всякой причины.
Все это детали реализации, а не договорные. Контрактное требование состоит в том, что вы снимаете блокировку SRWLock из того же потока, в котором она была получена. Если вы не будете следовать этому правилу, то поведение будет неопределенным, и ваша программа будет вести себя хаотично и неопределенным образом.
Так что не делайте этого. Соблюдайте правила и никто не пострадает.
Блокировка SRW должна быть снята тем же потоком, который ее захватил.
Спросили, что пойдет не так, если нарушить это правило, потому что в документации об этом не сказано.
В документации не сказано, что пойдет не так, потому что операция не поддерживается, поэтому поведение не определено. Вам не нужно определять неопределенное поведение.
Тем не менее, один из членов команды ядра объяснил, что пошло не так.
Система отслеживает, какой поток получил блокировку SRWLock, чтобы иметь возможность работать со сценариями инверсии приоритета: если поток с низким приоритетом получает блокировку SRWLock, а поток с более высоким приоритетом блокируется в ожидании получения блокировки SRWLock, поток переносится в поток-владелец.
Эта информация, помогающая избежать инверсии приоритетов, хранится в предварительно выделенных данных для каждого потока.
Если вы освободите SRWLock из потока, отличного от того, который его захватил, то внутренняя бухгалтерия испортится. Наиболее вероятным результатом является то, что передача приоритета получающему потоку никогда не удаляется (поскольку он был очищен не тем потоком). С точки зрения стороннего наблюдателя, это выглядит так, будто приоритет приобретающего потока постоянно повышался без какой-либо причины.
Разработчики ядра не сказали, но я подозреваю, что еще одним последствием является то, что любая передача приоритета освобождающему потоку удаляется преждевременно, поэтому похоже, что приоритет освобождающего потока был понижен без всякой причины.
Все это детали реализации, а не договорные. Контрактное требование состоит в том, что вы снимаете блокировку SRWLock из того же потока, в котором она была получена. Если вы не будете следовать этому правилу, то поведение будет неопределенным, и ваша программа будет вести себя хаотично и неопределенным образом.
Так что не делайте этого. Соблюдайте правила и никто не пострадает.
Похожие публикации
Нет комментариев