title: Race condition in glibc/NPTL/Linux robust mutexes?
body: <p>In a comment on the question <a href="https://stackoverflow.com/questions/4149266/automatically-release-mutex-on-crashes-in-unix?rq=1">Automatically release mutex on crashes in Unix</a> back in 2010, jilles claimed:</p>
  
  <blockquote>
    <p>glibc's robust mutexes are so fast because glibc takes dangerous shortcuts. There is no guarantee that the mutex still exists when the kernel marks it as "will cause EOWNERDEAD". If the mutex was destroyed and the memory replaced by a memory mapped file that happens to contain the last owning thread's ID at the right place and the last owning thread terminates just after writing the lock word (but before fully removing the mutex from its list of owned mutexes), the file is corrupted. Solaris and will-be-FreeBSD9 robust mutexes are slower because they do not want to take this risk.</p>
  </blockquote>
  
  <p>I can't make any sense of the claim, since destroying a mutex is not legal unless it's unlocked (and thus not in any thread's robust list). I also can't find any references searching for such a bug/issue. Was the claim simply erroneous?</p>
  
  <p>The reason I ask and that I'm interested is that this is relevant to the correctness of my own implementation built upon the same Linux robust-mutex primitive.</p>