Re: Early releases of lock in mamaSubscription destroy/deallocate logic
Slade, Michael J
Thank you for your reply Bill.
To get around the problem with attempting to destroy the mutex while it is locked, could we instead define our own wrapper around a recursive mutex which handles the following:
1. Keep a count of how many locks have been performed by current thread.
2. Defer destroy to unlock call if mutex currently locked.
This will keep all destroy/deallocate logic thread safe and stop the need for early unlocks.
From: Bill Torpey [mailto:wallstprog@...]
Sent: 01 April 2020 18:10
To: Slade, Michael J (CIB Tech, GBR) <michael.j.slade@...>
Subject: Re: [Openmama-dev] Early releases of lock in mamaSubscription destroy/deallocate logic
As far as I can tell, there’s no perfect solution here. From https://linux.die.net/man/3/pthread_mutex_destroy
So you either destroy the locked mutex, which is UB, or you unlock it first. In the second case, another thread could grab it, which would likely cause a crash at some point.
You can make the second problem go away by doing something like queueing the actual destroy in such a way that you know for certain that no other threads are waiting on the mutex, but that’s a fair bit of work, and tricky in its own right. We took that approach in our application, and it generally works well, and avoids a whole host of lifetime-related problems in OpenMAMA.
This message is confidential and subject to terms at: https://www.jpmorgan.com/emaildisclaimer including on confidential, privileged or legal entity information, viruses and monitoring of electronic messages. If you are not the intended recipient, please delete this message and notify the sender immediately. Any unauthorized use is strictly prohibited.