Lock acquisition by the same thread - deadlock protection

[Cameron Simpson]

On 12Mar2020 20:08, Dieter Maurer <dieter at handshake.de> wrote:
>Yonatan wrote at 2020-3-11 16:24 +0200:
>>That code I'm talking about didn't require a reentrant lock - the
>>algorithm really wasn't reentrant.
>>
>>Let me clarify my point: I'm wondering why the non-reentrant lock
>>doesn't raise an exception immediately on this
>>erroneous situation.
>>I thought it could be altered, or at least we could add an option to
>>let a `threading.Lock` behave like a pthread
>>mutex in mode `PTHREAD_MUTEX_ERRORCHECK`: Disallow double locking by
>>same thread, disallow unlocking
>>by another thread.
>
>The documentation for the basic lock explicitely allows
>lock release by a foreign thread.
>As I understand the documentation, this lock type is by design
>very basic - a mechanism to implement higher level abstractions.
>I use other synchronisation mechanisms when the basic lock does
>not fit my requirements.

Aye. I have certainly gone:
- take lock associated with some task specific resource
- set up task
- kick off worker Thread (or queue worker function for later)
- worker releases the lock

However, having an error check mode disallowing attempts by the same 
Thread to take a Lock it itself took seems valuable. If the lock object 
has that piece of information (IIRC it does).

Cheers,
Cameron Simpson <cs at cskk.id.au> (formerly cs at zip.com.au)