Re: deadlocks

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.

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.

Stephen
--
Stephen Kellett
Object Media Limited    http://www.objmedia.demon.co.uk/software.html
Computer Consultancy, Software Development
Windows C++, Java, Assembler, Performance Analysis, Troubleshooting
.

Relevant Pages

  • Re: deadlocks
    ... >complex than several identical threads using the same locks. ... But 3 and 2 are not protecting A. ... I wouldn't call that a problem with releasing ...
    (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)
  • 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: 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)