Re: deadlocks

In article <Rks8+BClLUnDFwvR@xxxxxxxxxxxxxxxxxxxx>,
Stephen Kellett <snail@xxxxxxxxxxxxxxxxxxxx> wrote:
>In message <404o2bF18l4asU4@xxxxxxxxxxxxxx>, blmblm@xxxxxxxxxxxxx writes
>>If the other thread is performing the same sequence of acquisitions
>>(first 1, then 2, then 3), how is this a problem? The other thread
>>isn't going to attempt to acquire 2 until it has 1.
>
>In that trivial example I posted it isn't a problem. As I said, the
>problems I've come up against were convoluted examples a lot more
>complex than several identical threads using the same locks. Most
>software I've worked on is not multiple identical threads working with
>the same locks. It is multiple different threads working with the same
>locks plus their own locks, some of which may be used by other threads.
>The trivial examples people use in these discussions (this one included)
>do not represent the real world.
>
>>>o Possible data integrity problems as some locks will be released too
>>>early.
>>
>>Not agreed on this one.
>
>1.acquire
>modify A
>2.acquire
>modify B
>3.acquire
>modify C
>1.release
>at this point another thread can modify A <- potential damage
>3.release
>2.release
>
>The potential damage is because the A should be protected. Since you've
>unlocked (1) in the wrong order A is not protected. 3 and 2 may still be
>held for quite a long time. But 3 and 2 are not protecting A.

I don't understand your example here. You have three locks, numbered
1, 2, and 3? What does 1 represent? from the fact that you acquire
it just before modifying A, it would seem to be something you need to
hold to modify A -- but then if the code modifies A after releasing
this lock, then .... I wouldn't call that a problem with releasing
locks in the wrong order so much as with failing to protect A by
only modifying it while holding the associated lock. You would
have the same problem if you released the three locks in the "correct"
order, but modified A after releasing lock #1, wouldn't you?

>
>In a trivial example where the locks are acquired immediately one after
>each other there is no problem. Real world examples usually have locks
>acquired in different functions. Thus if you release one too early you
>are exposing data that should be protected to potential manipulation
>from another thread.
>
>>Maybe it would help if you could point me/us to an API for acquiring
>>and releasing resources that *does* have the kind of problems you're
>>talking about.
>
>Win32 EnterCriticalSection/LeaveCriticalSection and the equivalent java
>bytecode instructions for entering and leaving a monitor.
>

The first Google hit for the former is this ....

http://msdn.microsoft.com/library/en-us/dllproc/base/entercriticalsection.asp

from which it's not obvious why the problem you describe occurs.

I think we may have to leave this as an unsolved mystery (from my
point of view), since my guess is that neither of us has time to
pursue it the depth that would be required.

--
| B. L. Massingill
| ObDisclaimer: I don't speak for my employers; they return the favor.
.

Relevant Pages

  • Re: deadlocks
    ... Most software I've worked on is not multiple identical threads working with the same locks. ... modify A 2.acquire modify B 3.acquire modify C 1.release at this point another thread can modify A <- potential damage 3.release 2.release ... The potential damage is because the A should be protected. ... But 3 and 2 are not protecting A. ...
    (comp.lang.java.programmer)
  • Re: citroen xsara central locking problems
    ... locks then unlocks and i cannot lock the doors. ... You need to modify the central locking. ...
    (uk.rec.cars.modifications)
  • Re: deadlocks
    ... >2.release <- mistake. ... >with some other thread that is using some or all of these locks. ... If the other thread is performing the same sequence of acquisitions ... >Another issue not considered here is that releasing in the wrong order ...
    (comp.lang.java.programmer)
  • Re: [RFC] ext3/jbd race: releasing in-use journal_heads
    ... I think the biggest problem here is that there's really no ... > written rule protecting this stuff universally. ... As long as there's some overlap in the locks, ...
    (Linux-Kernel)
  • Re: [PATCH] x86: sparse_irq need spin_lock in alloc
    ... It would be nice to add a comment explaining what they are protecting, ... ok - i moved the locks next to the data structure they protect (the free ... int count = 0; ... while (cfg) { ...
    (Linux-Kernel)