SHARED is only supported when the pthread library does support spinlock, while in all other case it falls back into using atomic locks. Providing support only for a small fraction of environments without reporting errors or providing any alternative on other systems is difficult to accept.
I think I prefer your suggestion to integrate this with the atomic locks and provide a single mechanism to handle them. Regarding this do you think there will be a need to separate the spinlocks and the atomic locks? George. On Thu, Aug 14, 2014 at 11:40 AM, Dave Goodell (dgoodell) < dgood...@cisco.com> wrote: > 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 > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/08/15652.php >
