Open Bug 1904674 Opened 3 months ago Updated 15 days ago

Split DirectoryLockImpl::Acquire into a preparation phase and actual acquisition

Categories

(Core :: Storage: Quota Manager, task, P2)

task

Tracking

()

ASSIGNED

People

(Reporter: janv, Assigned: janv)

References

(Depends on 1 open bug, Blocks 2 open bugs)

Details

Attachments

(5 files)

DirectoryLockImpl::Acquire currently finds all blocked-on locks and then it actually registers the lock and sets all necessary dependencies. Asynchronous temporary storage initialization sometimes needs to evaluate blocked-on locks first and conditionally avoid acquisition of the lock. The problem is that the list of all directory locks needs to be then traversed twice. The list of all directory locks could be traversed only once if there's was a preparation method which would return a stack only object with a list of blocked-on locks. Asynchronous temporary storage initialization could use the prepared list and then if the lock needs to be acquired, the list would be passed (by moving the stack only object) to the Acquire method.

If we actually need to do it in reverse order is still a question, this patch
just aligns DirectoryLockImpl::LocksMustWaitFor with
DirectoryLockImpl::AcquireInternal.

This patch also changes DirectoryLockImpl::LocksMustWaitFor to use the new
common method.

Consumers can now either call DirectoryLockImpl::Acquire without an argument
which will do the preparation and acquisition or they can opt-in to call
DirectoryLockImpl::Prepare first and then DirectoryLockImpl::Acquire with the
object returned by DirectoryLockImpl::Prepare which will do the preparation
and acquisition separately.

Blocks: 1904941
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: