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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org