WHAT: Add a new "opal/threads/spinlock.h" header to OPAL that will typically use the OS spinlock primitives if present.
WHY: opal_mutex_t is too slow for some use cases and opal_atomic_lock_t is inefficiently implemented for most architectures WHEN: timeout is after next week's engineering call on Tuesday, 2014-08-19 As discussed at the June developer meeting, I propose this patch to add spinlocks to OPAL. There are at least a half dozen reasonable ways to implement spinlocks; which one is best will vary from platform to platform. In general, the OS spinlock implementations are well tested and efficient. We should usually be relying on those implementations instead of rolling our own. My primary criticism of this patch is that it muddies the waters a bit with opal_atomic_lock_t. An alternative approach would be to spend some time working on improving the opal_atomic_lock_t implementation, but I have two concerns with this approach: 1) It's very difficult for me to measure the potential performance impact of opal_atomic_lock_t modifications on all of the various platforms that we currently run on. Adding this new implementation allows component maintainers to decide if and when to convert to using the new facility. 2) There's a reasonable chance that I'll make a mistake. Writing tests for this stuff helps to catch the really basic errors, but it doesn't help as much with the really subtle mistakes. -Dave
0001-add-opal-threads-spinlock.h.patch
Description: 0001-add-opal-threads-spinlock.h.patch
