Closed uwiger closed 9 years ago
Sorry about the delay. The unit test, including the 5-node netsplit scenario for locks_leader, now passes.
Apparently, the 'majority_alive' lock requirement which was used by locks_leader before, is iffy, esp. when netsplit has occurred and nodes have different views of how many nodes are alive. This transition may take a lot longer than I expected, and leads to sustained competition for locks.
If there are no objections, I plan to merge this into master soon.
This could be used to update the uw-locks-branch on gproc?
I just noticed this branch is using HEAD of locks. Forget :D
I just noticed this branch is using HEAD of locks.
For now it does. I plan to change that. :)
Attempt to resolve Issue #7
leader
attribute toundefined
in response to a netsplit, and then hopes to get ahave_all_locks
message. However, if the agent has already sent such a message, it won't send it again, unless asked to. However, a#locks_info{}
message should arrive at any rate. If we are in thesafe_loop()
, we check whether we have the lock, and ourleader
attribute is set toundefined
. If so, we callbecome_leader()
.locks_agent:get_locks()
was due to locks being deleted on nodedown, that may have been logged in theinteresting
list. This list is an optimization, keeping track of locks that have a queue of more than one agent (the only ones we need to worry about for dependency analysis). When removing all locks on a certain node, or all instances of a certain object, make sure to also delete them frominteresting
.