Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #3439 > unrolled thread

Two locks question

Back to article view | Back to comp.programming.threads

Contents

  Two locks question Melzzzzz <mel@zzzzz.com> - 2016-09-05 13:44 +0200
    Re: Two locks question Kaz Kylheku <221-501-9011@kylheku.com> - 2016-09-05 14:51 +0000

#3439 — Two locks question

I have situation like this:

lock(a);
lock(b);
// code...
unlock(a);
unlock(b);

Can this cause problems, that is , does unlock order matters in this
case?

[toc] | [next] | [standalone]

#3440

On 2016-09-05, Melzzzzz <mel@zzzzz.com> wrote:
> I have situation like this:
>
> lock(a);
> lock(b);
> // code...
> unlock(a);
> unlock(b);
>
> Can this cause problems, that is , does unlock order matters in this
> case?

Unlock order makes a difference since it is a thread's externally
visible behavior. It doesn't make a difference as to the logical
existence of a deadlock (if that's the problem you're thinking of). The
unlock operations are monotonically increasing freedom by releasing
resources.

Suppose different sets of threads are waiting on or contending for locks
a and b. Unlocking 'a' first interacts with one set. Unlocking 'b' first
interacts with the other set.

Any behavior change, even if itself correct, can conceivably "tickle" a
some latent bug whose root cause is actually elsewhere.
That is to say, suppose some sort of bug exists (that doesn't depend on
the order of those two unlocks) but is somehow exposed by changing the
order.

(Of course, if there is such an issue, of course we want to *know*;
we just, if possible, don't want to learn about it from a user having
a problem in the field.)

Basically similar reasoning applies as to:

   free(a);
   free(b);

is there any difference in the order in which we free two objects to the
allocator? Of course, either order is correct, but it *can* make some
sort of difference (even in a single-threaded program) by interacting
with a (use-after-free bug) --- when a situation is incorrect in the
program as a whole, involving those objects.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming.threads

csiph-web