Am 08.03.2017 um 23:57 schrieb Christopher:
> I debugged an application to the following scenario:
>
>
> #include <mutex>
>
> std::mutex g_mutex;
>
> int main()
> {
>
> std::unique_lock<std::mutex> lock(g_mutex);
> lock.release();
> lock.lock();
> lock.release();
> }
>
>
> This throws on the second attempt to lock.
> I thought the difference between unique lock and lock guard was that unique lock allowed manually locking and unlocking. We cannot lock it twice?

Aside from that you've to use unlock() and not release():
unlock() releases ownership so you are unable to re-lock
the mutex.

On 6/15/2023 10:07 AM, Bonita Montero wrote:
> Am 08.03.2017 um 23:57 schrieb Christopher:
>> I debugged an application to the following scenario:
>>
>>
>> #include <mutex>
>>
>> std::mutex g_mutex;
>>
>> int main()
>> {
>>
>>          std::unique_lock<std::mutex> lock(g_mutex);
>>          lock.release();
>>          lock.lock();
>>          lock.release();
>> }
>>
>>
>> This throws on the second attempt to lock.
>> I thought the difference between unique lock and lock guard was that
>> unique lock allowed manually locking and unlocking. We cannot lock it
>> twice?
>
> Aside from that you've to use unlock() and not release():
> unlock() releases ownership so you are unable to re-lock
> the mutex.
>

what about a hand off algorithm. Pass the buck?

A has a reference, hands off to B, now A is null. B is current in a
single atomic operation. On and on...

https://youtu.be/oRrlRbGT-LU

;^)