Skip to content
GitLab
Menu
Projects
Groups
Snippets
Loading...
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
Menu
Open sidebar
itminedu
snf-ganeti
Commits
164a5bcb
Commit
164a5bcb
authored
Sep 30, 2008
by
Guido Trotter
Browse files
locking design: talk about removing locks
Reviewed-by: iustinp
parent
040408a3
Changes
1
Hide whitespace changes
Inline
Side-by-side
doc/design-2.0-locking.rst
View file @
164a5bcb
...
...
@@ -123,8 +123,8 @@ The API will have a way to grab one or more than one locks at the same time.
Any attempt to grab a lock while already holding one in the wrong order will be
checked for, and fail.
Adding
new
locks
~~~~~~~~~~~~~~~~
Adding
/Removing
locks
~~~~~~~~~~~~~~~~
~~~~~
When a new instance or a new node is created an associated lock must be added
to the list. The relevant code will need to inform the locking library of such
...
...
@@ -132,9 +132,14 @@ a change.
This needs to be compatible with every other lock in the system, especially
metalocks that guarantee to grab sets of resources without specifying them
explicitly.
The implementation of this will be handled in the locking library itself.
explicitly. The implementation of this will be handled in the locking library
itself.
Of course when instances or nodes disappear from the cluster the relevant locks
must be removed. This is easier than adding new elements, as the code which
removes them must own them exclusively or can queue for their ownership, and
thus deals with metalocks exactly as normal code acquiring those locks. Any
operation queueing on a removed lock will fail after its removal.
Asynchronous operations
~~~~~~~~~~~~~~~~~~~~~~~
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
.
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment