On 12Mar2020 20:08, Dieter Maurer <die...@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 <c...@cskk.id.au> (formerly c...@zip.com.au)
--
https://mail.python.org/mailman/listinfo/python-list
