<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi Klaus,<br>
    <br>
    you are right, if approved Medium lock order is "from parent to
    child", then there is nothing wrong in original VirtualBoxImpl.cpp
    code. Thanks a lot!<br>
    <br>
    Regards,<br>
    Alexander<br>
    <br>
    <div class="moz-cite-prefix">12.02.2015 14:22, Klaus Espenlaub
      пишет:<br>
    </div>
    <blockquote cite="mid:54DC8D05.70304@oracle.com" type="cite">
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
      Hi Alexander,<br>
      <br>
      this patch (the VirtualBoxImpl.cpp part) is loosening up
      synchronization a bit too much for my taste. The approved lock
      order for Medium instances is "from parent to child", which is why
      your MachineImpl.cpp change is a perfect catch (and solution,
      because the child lock is held unnecessarily).<br>
      <br>
      The VirtualBoxImpl.cpp part on the other hand uses the correct
      lock order, so I'm wondering if you have any evidence that this is
      actually solving any deadlock. Not disputing that the code should
      still work properly after the change (with a tiny bit less
      atomicity which isn't strictly required), but I suspect there was
      nothing wrong with it initially. If it played part of a deadlock
      then it's most likely the other party where the lock order is
      wrong. If you're running a debug build then the lock validator in
      the runtime is active and should catch anything fishy (unless it
      involves event semapshores as they have no owner).<br>
      <br>
      Feedback appreciated <span class="moz-smiley-s1"><span> :-) </span></span><br>
      <br>
      Klaus<br>
      <br>
      <br>
      <div class="moz-cite-prefix">On 30.01.2015 15:50, <a
          moz-do-not-send="true" class="moz-txt-link-abbreviated"
          href="mailto:a.urakov@drweb.com">a.urakov@drweb.com</a> wrote:<br>
      </div>
      <blockquote cite="mid:54CB9A32.8070604@drweb.com" type="cite">
        <meta content="text/html; charset=UTF-8"
          http-equiv="Content-Type">
        Diffs attached<br>
        <br>
        <div class="moz-cite-prefix">30.01.2015 17:49, <a
            moz-do-not-send="true" class="moz-txt-link-abbreviated"
            href="mailto:a.urakov@drweb.com">a.urakov@drweb.com</a>
          пишет:<br>
        </div>
        <blockquote cite="mid:54CB99FC.2090805@drweb.com" type="cite">
          <meta http-equiv="content-type" content="text/html;
            charset=UTF-8">
          Hello!<br>
          <br>
          We would like to contribute to VirtualBox under MIT license.
          We send our changes to fix bug described at <a
            moz-do-not-send="true" class="moz-txt-link-freetext"
            href="https://www.virtualbox.org/ticket/13789">https://www.virtualbox.org/ticket/13789</a>
          .<br>
          <br>
          The idea is that functions <i>Medium::removeRegistry()</i>
          and <i>Medium::addRegistry()</i> themselves take write locks
          on mediums, so we get read lock only for <i>Medium::getAnyMachineBackref()</i>
          call in <i>VirtualBox::unregisterMachine()</i> function. Also
          we release read lock on medium after we got its parent and
          before we are going to iterate through parents in <i>Machine::detachAllMedia()</i>
          function.<br>
          <br>
          Regards,<br>
          Alexander<br>
          <br>
        </blockquote>
          </blockquote>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
vbox-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:vbox-dev@virtualbox.org">vbox-dev@virtualbox.org</a>
<a class="moz-txt-link-freetext" href="https://www.virtualbox.org/mailman/listinfo/vbox-dev">https://www.virtualbox.org/mailman/listinfo/vbox-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>