- Why does vector::reserve() not grow exponentially - 4 Updates
- Is this really necessary - 1 Update
| Paavo Helde <myfirstname@osa.pri.ee>: Jun 16 09:08PM +0300 >> use for an atomic fetch_and_add (e.g. the ARM64 LDADD instruction or intel >> LOCK INC). > I'm confused. Either std::atomic is thread safe or it isn't. Which is it? Of course it is thread-safe, that's what the name 'atomic' means. Alas, there are many definitions of "thread-safe", so one might easily get confused. In the case of atomics, "thread-safe" at least means the value of a particular atomic is well-defined and predictable when the atomic is accessed from multiple threads. Whether it means anything more depends on the used memory order and other details. |
| scott@slp53.sl.home (Scott Lurndal): Jun 16 07:06PM >particular atomic is well-defined and predictable when the atomic is >accessed from multiple threads. Whether it means anything more depends >on the used memory order and other details. A good discussion of atomicity (from the ARM perspective) can be found in B2.2 of the ARMv8 ARM (DDI0487) B2.2 Atomicity in the Arm architecture Atomicity is a feature of memory accesses, described as atomic accesses. The Arm architecture description refers to two types of atomicity, single-copy atomicity and multi-copy atomicity. In the Armv8 architecture, the atomicity requirements for memory accesses depend on the memory type, and whether the access is explicit or implicit. For more information, see: · Requirements for single-copy atomicity. · Properties of single-copy atomic accesses on page B2-130. · Multi-copy atomicity on page B2-130. · Requirements for multi-copy atomicity on page B2-130. · Concurrent modification and execution of instructions on page B2-130. For more information about the memory types, see Memory type overview on page B2-126. Understanding atomicity at the application level requires understanding the underlying hardware characteristics. |
| Sam <sam@email-scan.com>: Jun 16 05:40PM -0400 Bonita Montero writes: >>> directly or indirectly uses malloc() because what I said. >> No, you cannot be assured of that. ... > It has nothting to do with the standard. Everything has to do with the standard. > I told you why this is the most reasonable assumption. No, you told me why you think it's "the most reasonable assumption". That doesn't make it so, and it's actually quite unreasonable. No experienced C++ developer will make that assumption. |
| Sam <sam@email-scan.com>: Jun 16 05:40PM -0400 Bonita Montero writes: >>> They don't. >> As usual, you are wrong. It's quite common in some circles. ... > It's quite stupid to do that. No, it is quite reasonable to follow the C++ standard. |
| Vir Campestris <vir.campestris@invalid.invalid>: Jun 16 09:38PM +0100 On 06/06/2021 23:22, Alf P. Steinbach wrote: > One can tell gcc (or at least g++) to use the less noisy and more > conventional, in short more reasonable, Intel syntax via option > `-masm=intel`, unless I recall the details of that incorrectly. Ah, that explains it all. Except why the GCC/ARM disassembly I occasionally look at in my day job is in Intel order... Thanks Andy |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment