- resent after someone made Spamhaus remove the @talktalk.net e-mail
blacklisting entry -


Didier Kryn <kryn@???> writes:

> 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).

This could refer to Java 'synchronized things'. But these provide some
kind of high-level synchronization object called 'a monitor' and
'mutexes' (mutual exclusion locks) are just a primitive necessary for
implementing one. And the "use just like the global variables you'd
otherwise use" seems to suggest a programming style you seem to consider
more universal than I do.

Assuming I filled in the blanks halfway correctly, that's still a
certain style of programming which is already not a terribly good idea
for a single-threaded application. Using it in a multi-threaded one
'multi-threads' the inherent problems. This would be an example how one
can utilize the potential of more 'modern' technical (shared memory
multi-processors aka 'multicore CPUs') to achieve the same effect
(create a total chaos) much faster :->.

[...]

>> In case it [hold more than one lock] 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?

A so-called deadlock occurs if one thread of execution holds a lock A
and tries to acquire another lock B while some other thread tries to
acquire A while holding B. This means thread #1 blocks until thread #2
releases B and thread #2 blocks until thread #1 release A. Since they're
now both blocked, none of them will ever release anything.

This can be avoided by ensuring that each thread which needs to hold A
and B acquired A first and B second.