On 03/29/2018 04:45 PM, Florian Weimer wrote: > On 03/29/2018 10:25 PM, Mark Reynolds wrote: >> We can not back out the atomic work >> because it's needed to address several issues in our server. First of all, I updated the request wiki page to answer some of John's questions. > > One thing that's still not clear to me: What happens on 32-bit > architectures which do not have 64-bit atomics? Are they buggy in a > different way, and you used 64-bit atomics to address this because > i686 is still the most important 32-bit architecture? It's supposed to fallback to mutexes, but apparently it does not happen on i686. This is what the original engineer said. For more background the entire conversation is in https://bugzilla.redhat.com/show_bug.cgi?id=1544386 > > Looking at slapi_atomic_load_64 and slapi_atomic_incr_64, on the pure > 32-bit architectures, you just use 32-bit counters instead of 64-bit > counters. So whatever problems you were trying to fix exist on armhfp > as well, and if the 32-bit atomics aren't good enough, you have to > exclude armhfp as well. > > Do you have a reproducer for the issues you are trying to fix? I believe it's our cmocka tests that occur at rpm package time that brought this to our attention. So it is easy to reproduce. > I can try to put something together which uses a different type for > 64-bit atomics which has the proper 8-byte alignment, which will > eliminate the known cause of incorrect CAS results on i686. I would love to test whatever you have! Thanks, Mark > > Thanks, > Florian > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
