Есть ли причина использовать обычную блокировку над рекурсивной блокировкой?

Question

Когда поток снова пытается получить рекурсивную блокировку, которую он уже удерживает, rlock.acquire() позволяет продолжить поток и не блокирует поток.

Когда, с другой стороны, поток пытается получить обычную блокировку, которую он уже удерживает, тогда поток просто застревает в тупике.

Второй случай кажется мне источником неприятностей, так как это ситуация, которую нельзя легко восстановить (поток просто застрял на lock.acquire()), и это довольно сложно диагностировать (исключение не выбрасывается) или еще что-нить просто застряло)

Я видел это довольно много раз, так что кто-то действительно хотел использовать RLock, но вместо этого использовал обычный Lock и потратил некоторое время на устранение этой проблемы. Хотя с другой стороны, я никогда не сталкивался с ситуацией, когда Lock был бы на самом деле лучше. Возможно, его можно использовать, когда существует действительно критическая часть кода, к которой один и тот же поток не должен обращаться дважды дважды, но для этого необходимо, чтобы код внутри этой критической части вызывал сам себя, что было бы чем-то это должно быть совершенно очевидно для программиста.

Итак, есть ли случай, когда Lock лучше, чем RLock? И если нет, то должны ли языковые дизайнеры постоянно предоставлять обычный Lock?

Answer 1

Предполагая, что это объекты блокировки Python, документация показывает, что они совершенно разные. Основные различия между ними:

• Блокировка может быть снята любым потоком, а не только тем, который его получил
• Rlock может быть освобожден только тем потоком, который получил
• Rlock должен быть освобожден один раз за каждый раз, когда он получен потоком

Таким образом, блокировка позволяет создавать схемы потоков, в которых блокировка получается в одном потоке, но снимается в другом потоке. Одним из примеров может быть конвейер потоков, обрабатывающих часть работы, рабочий распределитель получает блокировку, но он освобождается последним потоком в конвейере.