Patch: General locking (was Possible deadlock and solution)

[David Relson]

<x-flowed>
At 11:19 PM 10/1/02, Matthias Andree wrote:
>On Tue, 01 Oct 2002, David Relson wrote:
>
> > I do have a question on the release list code.  I notice that locks are
> > released in reverse order of their acquisition.  Is the order
> > important?  Would there be any problem in reversing the order?
>
>You'd usually clean up in the reverse order of allocation, last
>allocated, first freed. It's also simpler code-wise ;-)

Certainly, "last allocated, first freed" makes for nice nesting, like in 
parentheses and brackets.

Counting down to zero has a nice simplicity as well.  Of course, if 
counting down is so superior, then the locking should also be done via 
count down <My turn to duck and run ...>

(On a side note, have you ever worked with a machine architecture in which 
the index registers are _subtracted_ from the array address?  It makes for 
interesting assembly language coding.)

> > The reason that I ask is that Eric's multi-list code uses a singly linked
> > list, which has a distinct order for the processing.  Merging your code 
> and
> > his will be easy if the order doesn't matter, a bit more difficult if the
> > order _does_ matter.
>
>singly-linked lists stink <ducks & runs for cover>

Sometimes that's all that's needed.  For sure, they're easier to deal with 
than doubly-linked lists.  For the case in hand, with a linked list, one 
knows that allocation is done when the end of the list is reached.  No need 
to count !

>Seriously: The lock release order does not matter. The other application
>can only proceed if ALL locks are freed, and it does not matter which
>lock is the last one to be released.
>
>The important thing is to obtain the whole set of locks, and release all
>the locks we got right away if ANY lock failed. Acquiring all the locks
>in the same place is more a maintenance issue than a necessity, but
>you'd have a hard time tracking down deadlocks if you spread the locks
>around, and if you did not properly roll back the locks (release them),
>weee... I'd rather not like to debug such code.

Locks are theoretical for me.  Personally, I've not needed to use them, so 
I'm not up on all the subtleties.  Hence the question.

Anyhow, shortly after Gyepi releases his lock code, I'll have a release of 
the multi-list code (with a list interface to locking).

Cheers!

David

</x-flowed>