4 ms·

It's definitely .net. We've observed deadlocks in spin scenarios which came down to this implementation rather than our callers.

• jclulow 8y ago
  You're suggesting, then, that the spinlock implementation is not merely slower on some CPUs but actually _incorrect_? It seems more likely that your software had some combination of a deadlock and a race condition exposed by different lock timing -- inserting delays in execution is one way to expand race windows to reproduce these kinds of defects.
  • setquk 8y ago
    Yes I am suggesting the implementation is incorrect. We had a standalone test case for this which could reproduce the condition after a random wait of 1-45 minutes. I will dig it out and raise it against .Net Core if it's still valid there. The problem was GC initiated i.e. the entry into GC caused the deadlock to start with which the process never recovered from as it was spinlocking all threads and no resources were available to complete GC.
  • deleted 8y ago
    [deleted]