<html><head></head><body data-blackberry-caret-color="#00a8df" style="background-color: rgb(255, 255, 255); line-height: initial;"><div id="BB10_response_div" style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br style="display:initial"></div> <div id="response_div_spacer" style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br style="display:initial"></div> <div id="_signaturePlaceholder" style="font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">Sent from my BlackBerry 10 smartphone.</div> <table width="100%" style="background-color:white;border-spacing:0px;"> <tbody><tr><td id="_persistentHeaderContainer" colspan="2" style="font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);"> <div id="_persistentHeader" style="border-style: solid none none; border-top-color: rgb(181, 196, 223); border-top-width: 1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB Alpha Sans', 'Slate Pro'; font-size: 10pt;"> <div><b>From: </b>Ulf Wiger</div><div><b>Sent: </b>Tuesday, October 8, 2013 5:58 AM</div><div><b>To: </b>erlang questions</div><div><b>Subject: </b>[erlang-questions] ANN: locks (beta) - distributed lock manager and<br> leader election</div></div></td></tr></tbody></table><div id="_persistentHeaderEnd" style="border-style: solid none none; border-top-color: rgb(186, 188, 209); border-top-width: 1pt; font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);"></div><br><div id="_originalContent" style=""><br>https://github.com/uwiger/locks/<br><br>Many of you have heard me talk about a lock manager that I've been working on.<br><br>I think it's now in a state where I can invite people to take it for a spin. Some of you may be<br>interested primarily in the gen_leader-like leader election behavior. You may jump directly to that<br>description below.<br><br>Note that I consider this a *beta* release. There is a fairly interesting test suite, but the code has not<br>been used in anger yet.<br><br>The README is (for once) fairly extensive, including a fairly detailed discussion of the verification work done by Thomas Arts back in 1999-2000. I first designed the algorithm back in 1993, but it's taken quite a lot of "hammock time" (to quote Rich Hickey) to fit all details together.<br><br>A few notes on why I think this implementation is useful:<br><br>* It detects and resolves deadlocks in a distributed setting, in what we believe is an optimal way, given the assumption that the computers are faster than the network (i.e. trading CPU time for network efficiency).<br>No phantom deadlocks, and no central dependency graph. Note that in some interesting mnesia-based<br>applications, phantom deadlocks have been found to account for some 10-20% overhead in execution<br>time.<br><br>* Since only true deadlocks are acted upon (either surrendered or leading to transaction abort if requested), transactions do not need to be preemptively restarted, as is the case in deadlock prevention. This means that transaction can be more 'erlang-ish' in their behavior and use side-effects at their leisure.<br><br>* It supports replicated locks, as well as quorum requirements. The 'lock space' is hierarchical, supporting<br>both read and write locks, as well as upgrade of read locks to write locks.<br><br>* Locks can be monitored by third parties. The leader election behavior uses this, but it can also be<br>used for debugging.<br><br>== The locks_leader behavior ==<br><br>Another gen_leader variant? Well, yes. This behavior is closely modeled after gen_leader,<br>but has a few important differences:<br><br>* The name of the election group is the name of the lock used to resolve elections. This means candidates<br>don't have to have registered names, and there can be multiple candidates on any given node.<br><br>* Candidates join the group simply by competing for the lock; other candidates discover them through<br>the #locks_info{} notifications, so the candidate list doesn't have to be statically defined. Nodes are<br>easily added at run-time.<br><br>The classic gen_leader example, gdict, has been implemented on locks_leader:<br>https://github.com/uwiger/locks/tree/master/examples<br><br>My own plan is to integrate this into the kvdb DBMS, but also to move gproc over to it, making distributed gproc more dynamic and well suited to Erlang's distribution behavior.<br><br>Feedback, questions and bug reports are highly appreciated!<br><br>BR,<br>Ulf W<br><br>Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.<br>http://feuerlabs.com<br><br><br><br>_______________________________________________<br>erlang-questions mailing list<br>erlang-questions@erlang.org<br>http://erlang.org/mailman/listinfo/erlang-questions<br></div></body></html>