Multi-lock not operating correctly when multiple threads

[Joshua Harlow]

When there are multiple threads *using the same multilock object* it appears the multilock is being to conservative and aborting to early when a lock has already been acquired by another thread (instead of waiting for acquisition to proceed). This will result in the multilock code throwing 'Lock %s not previously released' and then doing releasing of locks that the thread actually doesn't own. This is undesirable and not the expected behavior when these types of objects are shared among > 1 thread.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/122887

[Joshua Harlow (harlowja)]

Reduced from critical to high after doing grep for usage and seeing that locations where it is used are currently fine. Fix should still be done to make it correct under threaded usage of a shared multilock object of course...

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/122887
Committed: https://git.openstack.org/cgit/openstack/taskflow/commit/?id=83690a20863702c3bcebc042d2edefe7161062a8
Submitter: Jenkins
Branch: master

commit 83690a20863702c3bcebc042d2edefe7161062a8
Author: Joshua Harlow <email address hidden>
Date: Fri Sep 19 15:41:45 2014 -0700

    Fix multilock concurrency when shared by > 1 threads

    Instead of raising thread errors when another thread
    has locks that the consuming thread wants to use just
    block and wait and release the correct locks on release
    to match the expected vs observed behavior.

    This makes it so that a single multilock object can be
    shared by many threads and each thread using the object
    will correctly obtain and release as expected...

    Fixes bug 1371814

    Change-Id: Ia21a05fe9249fa019a09c4f30beeb0770ded5150