Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #123809 > unrolled thread

std::atomic work as volatile, or not, I think not...

Back to article view | Back to comp.lang.c++

Contents

  std::atomic work as volatile, or not, I think not... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-10 21:51 -0700
    Re: std::atomic work as volatile, or not, I think not... David Brown <david.brown@hesbynett.no> - 2026-05-11 08:25 +0200
      Re: std::atomic work as volatile, or not, I think not... boltar@caprica.universe - 2026-05-11 08:28 +0000
        Re: std::atomic work as volatile, or not, I think not... David Brown <david.brown@hesbynett.no> - 2026-05-11 11:02 +0200
          Re: std::atomic work as volatile, or not, I think not... boltar@caprica.universe - 2026-05-11 10:59 +0000
            Re: std::atomic work as volatile, or not, I think not... David Brown <david.brown@hesbynett.no> - 2026-05-11 13:20 +0200
              Re: std::atomic work as volatile, or not, I think not... Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-11 13:22 +0200
                Re: std::atomic work as volatile, or not, I think not... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-11 13:00 -0700
              Re: std::atomic work as volatile, or not, I think not... boltar@caprica.universe - 2026-05-11 15:08 +0000
                Re: std::atomic work as volatile, or not, I think not... David Brown <david.brown@hesbynett.no> - 2026-05-11 22:19 +0200
                  Re: std::atomic work as volatile, or not, I think not... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-11 13:25 -0700
              Re: std::atomic work as volatile, or not, I think not... scott@slp53.sl.home (Scott Lurndal) - 2026-05-11 15:48 +0000
                Re: std::atomic work as volatile, or not, I think not... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-11 13:09 -0700
            Re: std::atomic work as volatile, or not, I think not... Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-11 13:21 +0200
            Re: std::atomic work as volatile, or not, I think not... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-11 12:48 -0700
              Re: std::atomic work as volatile, or not, I think not... red floyd <no.spam.here@its.invalid> - 2026-05-11 21:04 -0700
                Re: std::atomic work as volatile, or not, I think not... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-14 00:35 -0700
          Re: std::atomic work as volatile, or not, I think not... cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-11 11:53 +0000
            Re: std::atomic work as volatile, or not, I think not... David Brown <david.brown@hesbynett.no> - 2026-05-11 15:18 +0200
              Re: std::atomic work as volatile, or not, I think not... Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-11 15:20 +0200
                Re: std::atomic work as volatile, or not, I think not... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-11 12:54 -0700
    Re: std::atomic work as volatile, or not, I think not... "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2026-05-11 11:46 +0200
      Re: std::atomic work as volatile, or not, I think not... David Brown <david.brown@hesbynett.no> - 2026-05-11 12:40 +0200
        Re: std::atomic work as volatile, or not, I think not... Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-05-11 06:55 -0400
          Re: std::atomic work as volatile, or not, I think not... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-12 12:14 -0700
      Re: std::atomic work as volatile, or not, I think not... scott@slp53.sl.home (Scott Lurndal) - 2026-05-11 15:49 +0000
        Re: std::atomic work as volatile, or not, I think not... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-11 12:36 -0700

Page 1 of 2  [1] 2  Next page →

#123809 — std::atomic work as volatile, or not, I think not...

Well, how much god damn optimization is a 100% conforming compiler 
allowed to do on my std::atomics?

Can they be used as if they are "volatile", or not, damn seems not...? 
If I make three atomic stores, I better get those three atomic stores in 
my generated ASM or something, damn it!

But, I am not 100% sure this is guaranteed unless another thread is in 
there. I know every std::atomic impl I have seen is laced with volatile 
somewhere. But, is it required to be? Or, well, shit.

Well, damn. It seems that std::atomic might not be sufficient, and 
volatile needs to be used.

Look at the following code:

Is volatile ct_atomic_word aword = { 0 }; even legal?
_______________________________
#include <iostream>
#include <cstdint>
#include <atomic>

// humm... For certian use cases,
// volatile might be needed here, say
// for embeded work, controlling something,
// ect...

// or is std::atomic guaranteed to work

typedef std::uint32_t ct_word;
typedef std::atomic<ct_word> ct_atomic_word;


int main()
{
     ct_atomic_word aword = { 0 };

     // na... but, well, for tricky hardware work?
     // oh yeah. sucks. need that volatile.

     // is this even okay? Used with a std::atomic?
     //volatile ct_atomic_word aword = { 0 };

     {
         aword.store(1, std::memory_order_relaxed);
         aword.store(2, std::memory_order_relaxed);
         aword.store(3, std::memory_order_relaxed);
     }

     std::cout << "aword = " << aword.load(std::memory_order_relaxed) << 
std::endl;

     return 0;
}
_______________________________

[toc] | [next] | [standalone]

#123812

On 11/05/2026 06:51, Chris M. Thomasson wrote:
> Well, how much god damn optimization is a 100% conforming compiler 
> allowed to do on my std::atomics?
> 
> Can they be used as if they are "volatile", or not, damn seems not...? 
> If I make three atomic stores, I better get those three atomic stores in 
> my generated ASM or something, damn it!
> 
> But, I am not 100% sure this is guaranteed unless another thread is in 
> there. I know every std::atomic impl I have seen is laced with volatile 
> somewhere. But, is it required to be? Or, well, shit.
> 
> Well, damn. It seems that std::atomic might not be sufficient, and 
> volatile needs to be used.
> 

I very much hope to be corrected if someone thinks my reasoning below is 
incorrect - I am not an expert here by any means.

As far as I know, there is no requirement for atomic accesses to act 
like volatile accesses - they are not directly observable behaviour.  Of 
course, if there are multiple threads (and the compiler will normally 
have to assume that there are), it would normally be extremely difficult 
for the compiler to determine that a given atomic access does not have 
some effect on the results of other observable behaviour - hence it will 
generate code for the access.

However, here you have used "memory_order_relaxed".  Your code thus says 
nothing about orders.  All that your code says is that "aword" can be 
read as 0, 1, 2 or 3 by other threads - and that in the current thread, 
the final read will definitely be 3.  In fact, I think the compiler can 
assume that since "aword" is local and does not escape from main(), 
there is no non-UB way for another thread to see it at all - it can 
probably be eliminated entirely from the code.  At most, a single store 
is sufficient.

When testing this kind of thing, I recommend that you do not use 
<iostream> or any other kind of output, or even "main()".  Use 
godbolt.org, and look at the generated assembly.  IO calls will dominate 
the generated code and make it very difficult to see what is actually 
going on.  Instead, declare "extern int get_int(); extern void 
put_int(int);" functions and call them in your code to force the input 
or output effects with minimal generated code.


> Look at the following code:
> 
> Is volatile ct_atomic_word aword = { 0 }; even legal?
> _______________________________
> #include <iostream>
> #include <cstdint>
> #include <atomic>
> 
> // humm... For certian use cases,
> // volatile might be needed here, say
> // for embeded work, controlling something,
> // ect...
> 
> // or is std::atomic guaranteed to work
> 
> typedef std::uint32_t ct_word;
> typedef std::atomic<ct_word> ct_atomic_word;
> 
> 
> int main()
> {
>      ct_atomic_word aword = { 0 };
> 
>      // na... but, well, for tricky hardware work?
>      // oh yeah. sucks. need that volatile.
> 
>      // is this even okay? Used with a std::atomic?
>      //volatile ct_atomic_word aword = { 0 };
> 
>      {
>          aword.store(1, std::memory_order_relaxed);
>          aword.store(2, std::memory_order_relaxed);
>          aword.store(3, std::memory_order_relaxed);
>      }
> 
>      std::cout << "aword = " << aword.load(std::memory_order_relaxed) << 
> std::endl;
> 
>      return 0;
> }
> _______________________________
> 

[toc] | [prev] | [next] | [standalone]

#123815

On Mon, 11 May 2026 08:25:55 +0200
David Brown <david.brown@hesbynett.no> gabbled:
>On 11/05/2026 06:51, Chris M. Thomasson wrote:
>> Well, damn. It seems that std::atomic might not be sufficient, and 
>> volatile needs to be used.
>> 
>
>I very much hope to be corrected if someone thinks my reasoning below is 
>incorrect - I am not an expert here by any means.

Whats the point of std::atomic anyway? Just how often does a thread critical
section just require the test and set of a single value? And if you do
want to do that posix semaphores have been a thing since the early 90s
and SysV ones since at least the 80s if not earlier.

[toc] | [prev] | [next] | [standalone]

#123816

On 11/05/2026 10:28, boltar@caprica.universe wrote:
> On Mon, 11 May 2026 08:25:55 +0200
> David Brown <david.brown@hesbynett.no> gabbled:
>> On 11/05/2026 06:51, Chris M. Thomasson wrote:
>>> Well, damn. It seems that std::atomic might not be sufficient, and 
>>> volatile needs to be used.
>>>
>>
>> I very much hope to be corrected if someone thinks my reasoning below 
>> is incorrect - I am not an expert here by any means.
> 
> Whats the point of std::atomic anyway? Just how often does a thread 
> critical
> section just require the test and set of a single value? And if you do
> want to do that posix semaphores have been a thing since the early 90s
> and SysV ones since at least the 80s if not earlier.
> 

Atomics are for shared information /without/ needing semaphores, 
critical sections or other more expensive operations.  Read up about 
non-blocking or lock-free algorithms.

[toc] | [prev] | [next] | [standalone]

#123820

On Mon, 11 May 2026 11:02:19 +0200
David Brown <david.brown@hesbynett.no> gabbled:
>On 11/05/2026 10:28, boltar@caprica.universe wrote:
>> On Mon, 11 May 2026 08:25:55 +0200
>> David Brown <david.brown@hesbynett.no> gabbled:
>>> On 11/05/2026 06:51, Chris M. Thomasson wrote:
>>>> Well, damn. It seems that std::atomic might not be sufficient, and 
>>>> volatile needs to be used.
>>>>
>>>
>>> I very much hope to be corrected if someone thinks my reasoning below 
>>> is incorrect - I am not an expert here by any means.
>> 
>> Whats the point of std::atomic anyway? Just how often does a thread 
>> critical
>> section just require the test and set of a single value? And if you do
>> want to do that posix semaphores have been a thing since the early 90s
>> and SysV ones since at least the 80s if not earlier.
>> 
>
>Atomics are for shared information /without/ needing semaphores, 

The underlying implementation will be the same.

>critical sections or other more expensive operations.  Read up about 
>non-blocking or lock-free algorithms.

An atomic/semaphore is just a lock on a single value by another name.
Also IIRC the "+=" operation isn't atomic with std::atomic which is a bit
of a joke.

[toc] | [prev] | [next] | [standalone]

#123821

On 11/05/2026 12:59, boltar@caprica.universe wrote:
> On Mon, 11 May 2026 11:02:19 +0200
> David Brown <david.brown@hesbynett.no> gabbled:
>> On 11/05/2026 10:28, boltar@caprica.universe wrote:
>>> On Mon, 11 May 2026 08:25:55 +0200
>>> David Brown <david.brown@hesbynett.no> gabbled:
>>>> On 11/05/2026 06:51, Chris M. Thomasson wrote:
>>>>> Well, damn. It seems that std::atomic might not be sufficient, and 
>>>>> volatile needs to be used.
>>>>>
>>>>
>>>> I very much hope to be corrected if someone thinks my reasoning 
>>>> below is incorrect - I am not an expert here by any means.
>>>
>>> Whats the point of std::atomic anyway? Just how often does a thread 
>>> critical
>>> section just require the test and set of a single value? And if you do
>>> want to do that posix semaphores have been a thing since the early 90s
>>> and SysV ones since at least the 80s if not earlier.
>>>
>>
>> Atomics are for shared information /without/ needing semaphores, 
> 
> The underlying implementation will be the same.

<https://cppreference.com/cpp/thread#Semaphores>
<https://cppreference.com/cpp/atomic/atomic>

I don't know how you can see them as being similar, unless by "the 
underlying mechanism" you mean memory accesses along with 
processor-specific features like bus lock prefixes, 
load-locked/store-conditional sequences, CAS operations, memory barrier 
instructions, etc.

In particular, semaphores have blocking support - you can block until a 
semaphore is available.  Atomics do not block, and are critical to 
non-blocking algorithms.

> 
>> critical sections or other more expensive operations.  Read up about 
>> non-blocking or lock-free algorithms.
> 
> An atomic/semaphore is just a lock on a single value by another name.

Neither of them are locks.

> Also IIRC the "+=" operation isn't atomic with std::atomic which is a bit
> of a joke.
> 

The operator "+=" on std::atomic integer and pointer types is defined as 
"fetch_add(arg) + arg" - the operation on the atomic variable is atomic.

[toc] | [prev] | [next] | [standalone]

#123824

Am 11.05.2026 um 13:20 schrieb David Brown:

> In particular, semaphores have blocking support - you can block until a 
> semaphore is available.  Atomics do not block, and are critical to non- 
> blocking algorithms.

You can have a futex'd ::wait() on an atomic.

[toc] | [prev] | [next] | [standalone]

#123837

On 5/11/2026 4:22 AM, Bonita Montero wrote:
> Am 11.05.2026 um 13:20 schrieb David Brown:
> 
>> In particular, semaphores have blocking support - you can block until 
>> a semaphore is available.  Atomics do not block, and are critical to 
>> non- blocking algorithms.
> 
> You can have a futex'd ::wait() on an atomic.
> 

Yup. That's actually pretty neat for the std to support that.

[toc] | [prev] | [next] | [standalone]

#123829

On Mon, 11 May 2026 13:20:17 +0200
David Brown <david.brown@hesbynett.no> gabbled:
>On 11/05/2026 12:59, boltar@caprica.universe wrote:
>> On Mon, 11 May 2026 11:02:19 +0200
>> The underlying implementation will be the same.
>
><https://cppreference.com/cpp/thread#Semaphores>
><https://cppreference.com/cpp/atomic/atomic>
>
>I don't know how you can see them as being similar, unless by "the 
>underlying mechanism" you mean memory accesses along with 
>processor-specific features like bus lock prefixes, 
>load-locked/store-conditional sequences, CAS operations, memory barrier 
>instructions, etc.

Nice cut and paste. Yes, I'm talking about the CPU level.

>In particular, semaphores have blocking support - you can block until a 
>semaphore is available.  Atomics do not block, and are critical to 
>non-blocking algorithms.

And? Semaphores don't have to block.

>>> critical sections or other more expensive operations.  Read up about 
>>> non-blocking or lock-free algorithms.
>> 
>> An atomic/semaphore is just a lock on a single value by another name.
>
>Neither of them are locks.

They're locks in the sense that nothing else can touch the value while the
current thread is updating it. So if another thread tries it'll be blocked.
You can call it what you like but locking seems a good enough word to me.

>> Also IIRC the "+=" operation isn't atomic with std::atomic which is a bit
>> of a joke.
>> 
>
>The operator "+=" on std::atomic integer and pointer types is defined as 
>"fetch_add(arg) + arg" - the operation on the atomic variable is atomic.

Its not atomic at the code level so its effectively useless.

[toc] | [prev] | [next] | [standalone]

#123839

On 11/05/2026 17:08, boltar@caprica.universe wrote:
> On Mon, 11 May 2026 13:20:17 +0200
> David Brown <david.brown@hesbynett.no> gabbled:
>> On 11/05/2026 12:59, boltar@caprica.universe wrote:
>>> On Mon, 11 May 2026 11:02:19 +0200
>>> The underlying implementation will be the same.
>>
>> <https://cppreference.com/cpp/thread#Semaphores>
>> <https://cppreference.com/cpp/atomic/atomic>
>>
>> I don't know how you can see them as being similar, unless by "the 
>> underlying mechanism" you mean memory accesses along with processor- 
>> specific features like bus lock prefixes, load-locked/store- 
>> conditional sequences, CAS operations, memory barrier instructions, etc.
> 
> Nice cut and paste. Yes, I'm talking about the CPU level.
> 
>> In particular, semaphores have blocking support - you can block until 
>> a semaphore is available.  Atomics do not block, and are critical to 
>> non-blocking algorithms.
> 
> And? Semaphores don't have to block.

Of course you don't /have/ to block on a semaphore, but there's not much 
use of them if you don't.  You might as well just use an atomic counter, 
which is much cheaper.

You can't use an atomic object for blocking.  C++ has a nice interface 
that appears to do so, but it's actually using a futex or similar 
mechanism for the blocking.  Remember, an atomic int takes 4 bytes of 
space (on most platforms), just like an int, and a relaxed read or write 
is just a normal load or store - something that can block needs queues 
of blocked threads and OS calls.  They are different worlds.

> 
>>>> critical sections or other more expensive operations.  Read up about 
>>>> non-blocking or lock-free algorithms.
>>>
>>> An atomic/semaphore is just a lock on a single value by another name.
>>
>> Neither of them are locks.
> 
> They're locks in the sense that nothing else can touch the value while the
> current thread is updating it. So if another thread tries it'll be blocked.
> You can call it what you like but locking seems a good enough word to me.
> 

That is not what anyone else means by locks (in this context).  A lock 
is something you use to control access to something else - not just to 
the single object.

>>> Also IIRC the "+=" operation isn't atomic with std::atomic which is a 
>>> bit
>>> of a joke.
>>>
>>
>> The operator "+=" on std::atomic integer and pointer types is defined 
>> as "fetch_add(arg) + arg" - the operation on the atomic variable is 
>> atomic.
> 
> Its not atomic at the code level so its effectively useless.
> 

That makes no sense at all.  "Atomic" does not mean "uses one assembly 
instruction".

[toc] | [prev] | [next] | [standalone]

#123840

On 5/11/2026 1:19 PM, David Brown wrote:
> On 11/05/2026 17:08, boltar@caprica.universe wrote:
>> On Mon, 11 May 2026 13:20:17 +0200
>> David Brown <david.brown@hesbynett.no> gabbled:
>>> On 11/05/2026 12:59, boltar@caprica.universe wrote:
>>>> On Mon, 11 May 2026 11:02:19 +0200
>>>> The underlying implementation will be the same.
>>>
>>> <https://cppreference.com/cpp/thread#Semaphores>
>>> <https://cppreference.com/cpp/atomic/atomic>
>>>
>>> I don't know how you can see them as being similar, unless by "the 
>>> underlying mechanism" you mean memory accesses along with processor- 
>>> specific features like bus lock prefixes, load-locked/store- 
>>> conditional sequences, CAS operations, memory barrier instructions, etc.
>>
>> Nice cut and paste. Yes, I'm talking about the CPU level.
>>
>>> In particular, semaphores have blocking support - you can block until 
>>> a semaphore is available.  Atomics do not block, and are critical to 
>>> non-blocking algorithms.
>>
>> And? Semaphores don't have to block.
> 
> Of course you don't /have/ to block on a semaphore, but there's not much 
> use of them if you don't.  You might as well just use an atomic counter, 
> which is much cheaper.
> 
> You can't use an atomic object for blocking.  C++ has a nice interface 
> that appears to do so, but it's actually using a futex or similar 
> mechanism for the blocking.  

Yeah. "Ideally", the futex is 100% separated from the atomics wrt its 
blocking logic. Usually hashed tables of wait queues in the kernel or 
wherever. For an impl detail, say the atomic can use a pointer to itself 
as a means to hash itself into a waitqueue. Kind of akin to:

https://groups.google.com/g/comp.lang.c++/c/sV4WC_cBb9Q/m/SkSqpSxGCAAJ



> Remember, an atomic int takes 4 bytes of 
> space (on most platforms), just like an int, and a relaxed read or write 
> is just a normal load or store - something that can block needs queues 
> of blocked threads and OS calls.  They are different worlds.


[...]

[toc] | [prev] | [next] | [standalone]

#123831

David Brown <david.brown@hesbynett.no> writes:
>On 11/05/2026 12:59, boltar@caprica.universe wrote:

>>>
>>> Atomics are for shared information /without/ needing semaphores, 
>> 
>> The underlying implementation will be the same.

That depends entirely on the instruction set of the target
processor.  Most of the modern architectures include
instructions to atomically modify a location in memory
(e.g. Fetch-and-add).   This is far more efficient
than attempting to acquire a spinlock or posix mutex
simply to update a single location in memory,
particularly when there are a significant number
of contenders (e.g. on a 128-core CPU).

This is essentially free in systems with
processor memory caching, since only one
processor (hardware thread) can own a cache line for write
access at any point in time.  The processor
simply sends the atomic op directly to the cache
(or if caches are bypassed, the memory controller)
for execution.

Those operations have been extended such that
modern hardware supports that level of atomicity
across PCI express and other interconnect
technologies.

The advantage of the cache coherency algorithm
efficiency vs LL/SC or LDEX/STREX is very signficiant.

ARM, for example, has atomic:

 - load and add (LDADD)
 - load and exclusive or (LDEOR)
 - load and clear bit (LDCLR)
 - load and set bit (LDSET)
 - load and return minimum value
 - load and return maximum value

[toc] | [prev] | [next] | [standalone]

#123838

On 5/11/2026 8:48 AM, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 11/05/2026 12:59, boltar@caprica.universe wrote:
> 
>>>>
>>>> Atomics are for shared information /without/ needing semaphores,
>>>
>>> The underlying implementation will be the same.
> 
> That depends entirely on the instruction set of the target
> processor.  Most of the modern architectures include
> instructions to atomically modify a location in memory
> (e.g. Fetch-and-add).   This is far more efficient
> than attempting to acquire a spinlock or posix mutex
> simply to update a single location in memory,
> particularly when there are a significant number
> of contenders (e.g. on a 128-core CPU).
> 
> This is essentially free in systems with
> processor memory caching, since only one
> processor (hardware thread) can own a cache line for write
> access at any point in time.  The processor
> simply sends the atomic op directly to the cache
> (or if caches are bypassed, the memory controller)
> for execution.
> 
> Those operations have been extended such that
> modern hardware supports that level of atomicity
> across PCI express and other interconnect
> technologies.
> 
> The advantage of the cache coherency algorithm
> efficiency vs LL/SC or LDEX/STREX is very signficiant.
> 
> ARM, for example, has atomic:
> 
>   - load and add (LDADD)
>   - load and exclusive or (LDEOR)
>   - load and clear bit (LDCLR)
>   - load and set bit (LDSET)
>   - load and return minimum value
>   - load and return maximum value

Is neat that ARM supports LL/SC _and_ the atomic RMW's.

[toc] | [prev] | [next] | [standalone]

#123823

Am 11.05.2026 um 12:59 schrieb boltar@caprica.universe:

> An atomic/semaphore is just a lock on a single value by another name.
> Also IIRC the "+=" operation isn't atomic with std::atomic which is
> a bit of a joke.
It is a atomic. But the memory-ordering is fixed to memory_order_seq_cst.

[toc] | [prev] | [next] | [standalone]

#123835

On 5/11/2026 3:59 AM, boltar@caprica.universe wrote:
> On Mon, 11 May 2026 11:02:19 +0200
> David Brown <david.brown@hesbynett.no> gabbled:
>> On 11/05/2026 10:28, boltar@caprica.universe wrote:
>>> On Mon, 11 May 2026 08:25:55 +0200
>>> David Brown <david.brown@hesbynett.no> gabbled:
>>>> On 11/05/2026 06:51, Chris M. Thomasson wrote:
>>>>> Well, damn. It seems that std::atomic might not be sufficient, and 
>>>>> volatile needs to be used.
>>>>>
>>>>
>>>> I very much hope to be corrected if someone thinks my reasoning 
>>>> below is incorrect - I am not an expert here by any means.
>>>
>>> Whats the point of std::atomic anyway? Just how often does a thread 
>>> critical
>>> section just require the test and set of a single value? And if you do
>>> want to do that posix semaphores have been a thing since the early 90s
>>> and SysV ones since at least the 80s if not earlier.
>>>
>>
>> Atomics are for shared information /without/ needing semaphores, 
> 
> The underlying implementation will be the same.
> 
>> critical sections or other more expensive operations.  Read up about 
>> non-blocking or lock-free algorithms.
> 
> An atomic/semaphore is just a lock on a single value by another name.

Take a deep look at:

https://en.cppreference.com/cpp/atomic/atomic/is_lock_free

https://en.cppreference.com/cpp/atomic/atomic/is_always_lock_free

https://en.cppreference.com/cpp/atomic/atomic_is_lock_free

The _fun_ part:

Expands to an integer constant expression with value
0 for the built-in atomic types that are never lock-free,
1 for the built-in atomic types that are sometimes lock-free,
2 for the built-in atomic types that are always lock-free.

sometimes is fun. wow....

Fwiw, you can mock up an atomic type that is never lock-free using 
hashing into a lock table.

(read all)
https://groups.google.com/g/comp.lang.c++/c/sV4WC_cBb9Q/m/SkSqpSxGCAAJ



> Also IIRC the "+=" operation isn't atomic with std::atomic which is a bit
> of a joke.
> 

Ever heard of fetch_and_add? The impl can use an atomic RMW for it.

[toc] | [prev] | [next] | [standalone]

#123843

On 5/11/2026 12:48 PM, Chris M. Thomasson wrote:
[redacted]
> https://en.cppreference.com/cpp/atomic/atomic/is_lock_free
> 
> https://en.cppreference.com/cpp/atomic/atomic/is_always_lock_free
> 
> https://en.cppreference.com/cpp/atomic/atomic_is_lock_free
> 
> The _fun_ part:
> 
> Expands to an integer constant expression with value
> 0 for the built-in atomic types that are never lock-free,
> 1 for the built-in atomic types that are sometimes lock-free,
> 2 for the built-in atomic types that are always lock-free.
> 
Would have been nice to have:

-1 = sometimes
  0 = never
  1 = always

So that the spaceship operator could be used.

[toc] | [prev] | [next] | [standalone]

#123858

On 5/11/2026 9:04 PM, red floyd wrote:
> On 5/11/2026 12:48 PM, Chris M. Thomasson wrote:
> [redacted]
>> https://en.cppreference.com/cpp/atomic/atomic/is_lock_free
>>
>> https://en.cppreference.com/cpp/atomic/atomic/is_always_lock_free
>>
>> https://en.cppreference.com/cpp/atomic/atomic_is_lock_free
>>
>> The _fun_ part:
>>
>> Expands to an integer constant expression with value
>> 0 for the built-in atomic types that are never lock-free,
>> 1 for the built-in atomic types that are sometimes lock-free,
>> 2 for the built-in atomic types that are always lock-free.
>>
> Would have been nice to have:
> 
> -1 = sometimes
>   0 = never
>   1 = always
> 
> So that the spaceship operator could be used.
> 

Shit man, been a while since I used the sucker!

[toc] | [prev] | [next] | [standalone]

#123825

In article <10ts5ur$updt$2@dont-email.me>,
David Brown  <david.brown@hesbynett.no> wrote:
>On 11/05/2026 10:28, boltar@caprica.universe wrote:
>> On Mon, 11 May 2026 08:25:55 +0200
>> David Brown <david.brown@hesbynett.no> gabbled:
>>> On 11/05/2026 06:51, Chris M. Thomasson wrote:
>>>> Well, damn. It seems that std::atomic might not be sufficient, and 
>>>> volatile needs to be used.
>>>>
>>>
>>> I very much hope to be corrected if someone thinks my reasoning below 
>>> is incorrect - I am not an expert here by any means.
>> 
>> Whats the point of std::atomic anyway? Just how often does a thread 
>> critical
>> section just require the test and set of a single value? And if you do
>> want to do that posix semaphores have been a thing since the early 90s
>> and SysV ones since at least the 80s if not earlier.
>> 
>
>Atomics are for shared information /without/ needing semaphores, 
>critical sections or other more expensive operations.  Read up about 
>non-blocking or lock-free algorithms.

And also for implementing such things.

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#123826

On 11/05/2026 13:53, Dan Cross wrote:
> In article <10ts5ur$updt$2@dont-email.me>,
> David Brown  <david.brown@hesbynett.no> wrote:
>> On 11/05/2026 10:28, boltar@caprica.universe wrote:
>>> On Mon, 11 May 2026 08:25:55 +0200
>>> David Brown <david.brown@hesbynett.no> gabbled:
>>>> On 11/05/2026 06:51, Chris M. Thomasson wrote:
>>>>> Well, damn. It seems that std::atomic might not be sufficient, and
>>>>> volatile needs to be used.
>>>>>
>>>>
>>>> I very much hope to be corrected if someone thinks my reasoning below
>>>> is incorrect - I am not an expert here by any means.
>>>
>>> Whats the point of std::atomic anyway? Just how often does a thread
>>> critical
>>> section just require the test and set of a single value? And if you do
>>> want to do that posix semaphores have been a thing since the early 90s
>>> and SysV ones since at least the 80s if not earlier.
>>>
>>
>> Atomics are for shared information /without/ needing semaphores,
>> critical sections or other more expensive operations.  Read up about
>> non-blocking or lock-free algorithms.
> 
> And also for implementing such things.
> 

Indeed.  Both volatiles and atomics (or volatile atomics) are useful in 
the implementation of semaphores and other kinds of synchronisation, 
locking, and concurrency types.  Standard atomics reduce the need for 
compile-specific extensions.

[toc] | [prev] | [next] | [standalone]

#123827

Am 11.05.2026 um 15:18 schrieb David Brown:

> Indeed.  Both volatiles and atomics (or volatile atomics) are useful in 
> the implementation of semaphores and other kinds of synchronisation, 
> locking, and concurrency types. ...

volatile doesn't make sense for that purpose.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web