var lockObj = new Object();
if (Monitor.TryEnter(lockObj)) {
try {
// The critical section.
}
finally {
// Ensure that the lock is released.
Monitor.Exit(lockObj);
}
}
else {
// The lock was not axquired.
}
КД>Если я все правильно понял, то: System.Threading.Monitor.IsEntered(lockObject)
Вернет true если текущий поток держит лок. Насколько я понял ТС, ему нужно не это.
Хотя, могу ошибаться. Формулировка вопроса не совсем ясная.
Здравствуйте, Muxa, Вы писали: КД>>Если я все правильно понял, то: System.Threading.Monitor.IsEntered(lockObject) M>Вернет true если текущий поток держит лок. Насколько я понял ТС, ему нужно не это. M>Хотя, могу ошибаться. Формулировка вопроса не совсем ясная.
Да, точно.
Я на это (то что это про текущий поток) не обратил внимание, когда смотрел название метода в своем коде
Здравствуйте, Muxa, Вы M>Хотя, могу ошибаться. Формулировка вопроса не совсем ясная.
Есть как минимум два потока. Один работает с методом внутренность которого закрыта оператором lock от третьего, четвертого... потоков. В первом потоке может возникнуть ситуация, когда нужно знать заблокировал второй поток блок кода или нет. Если в двух словах, если занят — немного подождать освобождение. Но! Поскольку заблокированный код теоретически может зависнуть сильно надолго (работа с внешними удаленными сервисами), а первый долго ждать не может, то вариант с семафором ожидания не подходит. Другое "но" из первого потока метод с блокировкой НЕ запускается, нужно лишь знать о состоянии второго потока.
Здравствуйте, CyberRussia, Вы писали:
CR>Здравствуйте, Muxa, Вы M>>Хотя, могу ошибаться. Формулировка вопроса не совсем ясная.
CR>Но! Поскольку заблокированный код теоретически может зависнуть сильно надолго (работа с внешними удаленными сервисами)
Вот это сама по себе проблема — работать с внешними сервисами из под локального лока. Особенно, если внешние сервисы работают с чем-то еще.