So, is this hardware limitation something that is likely to affect other packages? Is there something we could look for in how they consume atomic types to tell? I would hate for us to ship something else that is subject to this problem.
<<big snip>>
The way I read some of the comments on the bugs in reviewing the code it seems it could just as well happen on any architecture, it's just easier to trigger (I explicitly steer clear of the term reproduce) on i686.
A 64-bit atomic operation must have a memory operand that is 8-byte aligned. Not being 8-byte aligned is likely to cause problems on every architecture. In particular, if the 64-bit memory operand straddles a cache-line boundary (resides partly in one cache line and partly in the next cache line) then it may be impossible to guarantee atomic. The hardware will "try" anyway, but can produce bad results easily: double increment, total garbage, etc. If one part of the straddle is a cache hit but the other part is a miss, then chaos can result easily. https://bugzilla.redhat.com/show_bug.cgi?id=1544386#c26 and #c27 identify that alignof(long long) _in a struct_ is only 4 (and not 8) for GCC on i386. This is a mistake, perhaps in the ABI. Being aware of the deficiency, then GCC for i686 should detect badness at runtime: test $7,addr; beq OK; hlt OK: cmpxchg8b ... unless GCC can prove 8-byte aligned at compile time. The code in 389-ds-base that deals with parallelism is poor. It contains multiple problems with Memory Ordering, and needs extensive work even on 64-bit architectures. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
