<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>On 9/15/19 10:22 PM, Conor McCarthy wrote:<br>
    </p>
    <blockquote type="cite"
cite="mid:CAOua6-98WV3pZmcOxwJ-gA1e4EkzvB1U69zYEfb7EPu74T6eHw@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div class="gmail_quote">
          <div dir="ltr" class="gmail_attr">On Sat, Sep 14, 2019 at
            12:20 AM Derek Lesho <<a
              href="mailto:dlesho@codeweavers.com"
              moz-do-not-send="true">dlesho@codeweavers.com</a>>
            wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex">
            +    pthread_spin_lock(descriptor->lock);
            <br>
          </blockquote>
          <div><br>
          </div>
          <div>I think this isn't thread safe. If a thread tries to lock
            descriptor->lock when another thread has memset the
            descriptor to 0, it will crash if pthread_spin_lock()
            doesn't check for null.</div>
          <div><br>
          </div>
          <div>For performance reasons I think we need to test the
            possibility that any thread which meets a locked descriptor
            can skip the operation entirely. This would save spinning on
            the lock and an extra descriptor write. If two threads are
            writing the same descriptor simultaneously, this implies
            it's essentially random which thread sets what data, so
            maybe it will work if only the first thread writes the
            descriptor. Skipping can be done with
            pthread_spin_trylock(), but InterlockedCompareExchange()
            would be simpler.<br>
          </div>
        </div>
      </div>
    </blockquote>
    You're right, I did overlook that (descriptor->lock being NULL). 
    I'll try your idea to discard writes when one is already in progress
    with SOTTR, that solution should be faster.<br>
  </body>
</html>