It is on two different threads - the IPC thread calls buffer->callback (), the application thread calls ~BufferVault. I don't think a recursive mutex helps here?
On 26 July 2017 6:41:46 pm AEST, Alan Griffiths <email address hidden> wrote:
>Review: Needs Information
>
>> The RPC subsystem calls buffer->callback(), which takes
>> AtomicCallback::mutex and then calls
>BufferVault::wire_transfer_inbound...
>> which immediately takes BufferVault::mutex.
>
>This (pre-existing code) is hard to reason about, the extra logic
>doesn't help.
>
>Would it be any more complex to make BufferVault::mutex a
>std::recursive_mutex? (The above is all on a single thread.)
>--
>https://code.launchpad.net/~raof/mir/fix-lock-inversion/+merge/328069
>You are the owner of lp:~raof/mir/fix-lock-inversion.
It is on two different threads - the IPC thread calls buffer->callback (), the application thread calls ~BufferVault. I don't think a recursive mutex helps here?
On 26 July 2017 6:41:46 pm AEST, Alan Griffiths <email address hidden> wrote: :mutex and then calls :wire_transfer_ inbound. .. _mutex? (The above is all on a single thread.) /code.launchpad .net/~raof/ mir/fix- lock-inversion/ +merge/ 328069
>Review: Needs Information
>
>> The RPC subsystem calls buffer->callback(), which takes
>> AtomicCallback:
>BufferVault:
>> which immediately takes BufferVault::mutex.
>
>This (pre-existing code) is hard to reason about, the extra logic
>doesn't help.
>
>Would it be any more complex to make BufferVault::mutex a
>std::recursive
>--
>https:/
>You are the owner of lp:~raof/mir/fix-lock-inversion.