On Mon, Aug 6, 2018 at 1:16 AM, Andrew Haley <aph@redhat.com> wrote:
On 08/05/2018 04:30 PM, Martin Buchholz wrote:
Here's one example of code that actually did go wrong with Google's latest internal toolchain, because the copy was not in fact word-atomic. Thanks to whoever added the comment long ago.
static inline void copy_table(address* from, address* to, int size) { // Copy non-overlapping tables. The copy has to occur word wise for MT safety. while (size-- > 0) *to++ = *from++; }
Recommendation: target C++11 for jdk12; I don't think that helps. There's no legal way AFAICS to force an atomic access to non-atomic types in C++11.
Ohh... perhaps that's the idea behind atomic_ref https://en.cppreference.com/w/cpp/atomic/atomic_ref we only have to wait one more decade for that to become available. I don't know what is actually being copied here, but can't the underlying type be atomic<address*> ?
On Aug 6, 2018, at 9:54 PM, Martin Buchholz <martinrb@google.com> wrote:
I don't know what is actually being copied here, but can't the underlying type be atomic<address*> ?
Yes, if we are allowed to cast some random sequence of metadata words to atomic<address*>[]. If that's the magic incantation to get to the hardware's atomicity primitives, OK. I suspect a more direct technique may be needed, such as assembly code stubs. — John
participants (2)
-
John Rose
-
Martin Buchholz