Le 26/07/2016 12:59, Rainer Weikusat a écrit :
> Didier Kryn <kryn@???> writes:
>> Le 25/07/2016 01:29, Rainer Weikusat a écrit :
>>> Sleeping on a contended mutex is implemented in this way. But that's
>>> supposed to be an exceptional case.
>> This is why, while advertizing itself as a cool "don't care"
>> feature, a mutex is problematic:
> I don't know who's advertising that "don't care" use of shared variables
> would be "cool" and who's being targetted by this advertising (and I
> don't even want to know) but I don't share this opinion. This applies
> equally to single-threaded and multi-threaded applications. A mutex is a
> synchronisation primitive useful for implementing userspace inter-thread
> communication facilities (this is a bit too general).
>
This bias of mine comes from the fact that, in high level
languages, mutexes are embedded inside dedicated objects, and the
application can assign values to these objects exactly as it would do
for any other object (without specific care).
I absolutely expected you wouldn't share my opinion :->
>> the programmer should make sure contention is exceptional and there is
>> no risk of dead-lock.
> Mutexes (or any other kind of lock) should usually be uncontended if
> performance is considered important. It's often not necessary that
> threads hold more than one mutex at the same time.
Here we see that we probably think of very different uses cases.
> In case it is, care
> must be taken to ensure that they always try to acquire all members of
> the shared set of mutexes in the same order to avoid deadlocks.
>
All threads aquiring locks in the same order, this is equivalent to
having only one lock, no?
Didier