A surprise with mutexes and reference counts

Posted Dec 7, 2013 23:34 UTC (Sat) by giraffedata (guest, #1954)
In reply to: A surprise with mutexes and reference counts by sorokin
Parent article: A surprise with mutexes and reference counts

Whether it's a mutex bug depends upon what you expect from a mutex, in particular when you consider to be the instant the lock is released.

As we usually define timing in library calls, we would say the lock is released sometime during the execution of mutex_unlock(), with no more precision than that. In the same way, we would say that mutex_unlock() can access its arguments at any time during its execution. With that definition, you obviously cannot put the lock inside the object being protected by the lock, because that means the mutex_unlock() could conceivably access the protected object after it has released the lock.

But since that prevents a very useful locking paradigm -- one that allows an object to be somewhat autonomous and just disappear on its own when its last reference goes away -- most of us are used to a more precise guarantee: the lock gets released at some instant after mutex_unlock's last reference to the lock. I presume that's actually written into official specifications for things like POSIX mutexes.

That stronger guarantee is what the mutexes in question fail to provide; I don't know if the designer intended that or not. If he did, then the reference counting code that assumed the stronger guarantee is where the bug is.

A surprise with mutexes and reference counts

Posted Dec 10, 2013 8:13 UTC (Tue) by sorokin (guest, #88478) [Link]

> Whether it's a mutex bug depends upon what you expect
> from a mutex, in particular when you consider to be the
> instant the lock is released.

Completely argee. Whether the bug is in mutex or in reference counting code depends on the contract of the mutex. Still I believe, that mutex that can access mutex memory for undefinite amount of time after unlocking can be used safely only in very simple programs.

E.g. Linus said that you can keep mutex outside of object you are protecting. But this does not fix anything. How can we guarantee that CPU2 after removing reference counting object will not remove object where mutex reside? After removing reference counting object CPU2 can do anything.

As we decided that mutex that can access mutex memory for undefinite amount is not safe, the only valid kind of mutex is one that has some requirement when it stops accessing its memory after unlock. So I tried to devise those requirements.

> the lock gets released at some instant after mutex_unlock's last reference to the lock

This is very strong requirement. If it is feasible to implement effectively -- good, if not we can relax our requirement as I did.

A surprise with mutexes and reference counts

Posted Dec 10, 2013 8:20 UTC (Tue) by sorokin (guest, #88478) [Link]

Another solution can be having a function that must be called before mutex memory is freed. Something like C++ destructor for mutex. This function must ensure, that all other threads finished unlocking mutex.