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

Groups > comp.programming.threads > #3440

Re: Two locks question

Show all headers | View raw

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.

Back to comp.programming.threads | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

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

csiph-web