:: Re: [DNG] Wirth's law
Página Inicial
Delete this message
Reply to this message
Autor: Hendrik Boom
Data:  
Para: dng
Assunto: Re: [DNG] Wirth's law
On Wed, Jul 27, 2016 at 08:15:27AM +0200, Didier Kryn wrote:
> 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?


No.

The requirement isn't that a thread acquire all the locks. It's
that there be an ordering of locks so that if a thread acquires locks E, F,
G in that order, then E > F > G by the global order. There's no
requirement that some other thread can't acquire G without acquiring E
or F at all. What it can't do is acquire E or F after acquiring G.

-- hendrik