- Two locks question - 2 Updates
| Melzzzzz <mel@zzzzz.com>: Sep 05 01:44PM +0200 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? |
| Kaz Kylheku <221-501-9011@kylheku.com>: Sep 05 02:51PM > 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. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.programming.threads+unsubscribe@googlegroups.com. |
No comments:
Post a Comment