<div dir="ltr">Funneling all the calls through a single process would bring the system to a grinding halt. Sure, I could write a system of processes, each of which acts as a mutex to one, particular resource, but why would I want to? All I need is locking, just like global locks, but fair. It seems like something that should already exist in a proven library.<br><br><div class="gmail_quote"><div dir="ltr">On Mon, May 14, 2018 at 3:41 PM Michael Truog <<a href="mailto:mjtruog@gmail.com" target="_blank">mjtruog@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div class="m_8981983279651916709m_-4105019898078278160moz-cite-prefix">Use a single Erlang process.  It will
      only be able to handle a single message at a time (other messages
      will get queued in-order) and the behavior will be fair.</div></div><div text="#000000" bgcolor="#FFFFFF"><div class="m_8981983279651916709m_-4105019898078278160moz-cite-prefix">
      <br>
      On 05/14/2018 12:55 PM, Ryan Stewart wrote:<br>
    </div></div><div text="#000000" bgcolor="#FFFFFF"><blockquote type="cite">
      <div dir="ltr">My team has used global:set_lock() to implement a
        sort of simple mutex system on a set of resources. It turns out
        that this function seems to have no concept of fairness. One
        process might request a lock and not get it until 20 other
        processes have requested and gotten said lock, out of request
        order. Is there any easy way to do fair locking?<br>
      </div>
      </blockquote></div></blockquote></div></div>