[PATCH] D26232: [XRay][compiler-rt] XRay Buffer Queue

[Dean Michael Berris via Phabricator via llvm-commits]

dberris added a comment.

In https://reviews.llvm.org/D26232#605943, @rSerge wrote:

> I forgot one argument in favor of a spinlock: to alleviate the problem of sudden long-running operations (such as thread preemption), after spinning for N times (where N is such that 95% of times the guarded operation takes less time), the spinlock acquisition code should issue `std::this_thread::yield()`, so not to consume CPU if other threads have real work to do. Even though the CPU load with such approach is higher than with syscall-based mutexes, that load is effectively in background priority. While the responsiveness of spinlock is sub-nanosecond, while for a mutex it's on the order of microsecond.
>  But see yourself, perhaps it's not a good idea to optimize prematurely.


Yeah, I think we can do this later when we have a better idea as to the cost of the short critical section involved in updating the data structure (the deque). The spin lock should be fine with a yield after a few iterations, but can't tell whether this will be something worth optimising yet. :)

Trying to submit again now that we have some workarounds to the arm and aarch64 builds failing and being flaky.


Repository:
  rL LLVM

https://reviews.llvm.org/D26232