Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #69716 > unrolled thread
| Started by | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| First post | 2019-11-12 10:54 +0100 |
| Last post | 2019-11-14 11:45 +0100 |
| Articles | 20 on this page of 91 — 9 participants |
Back to article view | Back to comp.lang.c++
std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 10:54 +0100
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 11:24 +0100
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 14:11 +0100
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 14:39 +0100
Re: std::atomic<T>::is_lock_free() Bo Persson <bo@bo-persson.se> - 2019-11-12 16:46 +0100
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 17:40 +0100
Re: std::atomic<T>::is_lock_free() Bo Persson <bo@bo-persson.se> - 2019-11-12 20:23 +0100
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-12 15:21 -0800
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-14 13:09 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-13 06:34 +0100
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-13 22:00 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 07:26 +0100
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-13 22:33 -0800
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-13 22:33 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 07:51 +0100
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 07:50 +0100
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-13 23:14 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 10:43 +0100
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-12 15:14 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 13:11 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-14 07:53 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 16:57 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-14 08:16 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 17:26 +0100
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 17:28 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-14 08:30 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 17:33 +0100
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-14 13:41 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-15 09:31 +0100
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-15 12:59 -0800
Re: std::atomic<T>::is_lock_free() scott@slp53.sl.home (Scott Lurndal) - 2019-11-15 21:47 +0000
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-15 13:56 -0800
Re: std::atomic<T>::is_lock_free() scott@slp53.sl.home (Scott Lurndal) - 2019-11-16 18:07 +0000
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-16 13:55 -0800
Re: std::atomic<T>::is_lock_free() scott@slp53.sl.home (Scott Lurndal) - 2019-11-16 22:13 +0000
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-16 18:40 -0800
Re: std::atomic<T>::is_lock_free() James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-17 18:39 -0500
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-17 20:59 -0800
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-17 21:00 -0800
Re: std::atomic<T>::is_lock_free() James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-18 08:25 -0500
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-18 18:24 -0800
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-15 13:59 -0800
Re: std::atomic<T>::is_lock_free() Ian Collins <ian-news@hotmail.com> - 2019-11-16 11:08 +1300
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-15 15:39 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-16 07:22 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-16 08:06 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-16 17:13 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-16 08:26 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-16 19:27 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-16 10:37 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-16 19:47 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-16 11:34 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-17 09:17 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-17 01:52 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-17 11:23 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-17 03:22 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-17 14:20 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-17 06:39 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-17 15:49 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-17 22:54 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-18 08:03 +0100
Re: std::atomic<T>::is_lock_free() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 15:39 -0800
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-28 16:33 -0800
Re: std::atomic<T>::is_lock_free() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 22:48 -0800
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2020-01-11 00:24 -0800
Re: std::atomic<T>::is_lock_free() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-14 07:16 -0800
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2020-01-14 08:55 -0800
Re: std::atomic<T>::is_lock_free() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-21 02:01 -0800
Re: std::atomic<T>::is_lock_free() James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-21 06:00 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-17 15:58 +0100
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-17 21:01 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-18 07:00 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-17 22:45 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-18 07:52 +0100
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-18 08:10 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-17 23:23 -0800
Re: std::atomic<T>::is_lock_free() Ian Collins <ian-news@hotmail.com> - 2019-11-18 20:26 +1300
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-17 23:05 -0800
Re: std::atomic<T>::is_lock_free() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 15:44 -0800
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-28 16:43 -0800
Re: std::atomic<T>::is_lock_free() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-11 06:41 -0800
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-14 13:33 -0800
Re: std::atomic<T>::is_lock_free() Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-14 19:08 +0000
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 20:12 +0100
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-14 13:35 -0800
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-14 13:32 -0800
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-14 13:37 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-15 09:32 +0100
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-15 13:06 -0800
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-14 02:29 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 11:45 +0100
Page 1 of 5 [1] 2 3 4 5 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-12 10:54 +0100 |
| Subject | std::atomic<T>::is_lock_free() |
| Message-ID | <qqdvha$nka$1@news.albasani.net> |
Can anyone tell me whether std::atomic<T>::is_lock_free() isn't static as well as constexpr? Having it non-static as well as non-constexpr doesn't make sense for me.
[toc] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-12 11:24 +0100 |
| Message-ID | <qqe180$jhd$1@news.albasani.net> |
| In reply to | #69716 |
> Can anyone tell me whether std::atomic<T>::is_lock_free() isn't static > as well as constexpr? Having it non-static as well as non-constexpr > doesn't make sense for me. Someone on Stack Oveflow told me this: an atomic value might be un- aligned so that access might be not atomic. So the compiler can't say at compile-time whether the access can be atomic. But there's a static constexpr bool called std::atomic<T> ::is_always_lock_free.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-12 14:11 +0100 |
| Message-ID | <qqeb20$asj$1@news.albasani.net> |
| In reply to | #69717 |
>> Can anyone tell me whether std::atomic<T>::is_lock_free() isn't static >> as well as constexpr? Having it non-static as well as non-constexpr >> doesn't make sense for me. > Someone on Stack Oveflow told me this: an atomic value might be un- > aligned so that access might be not atomic. So the compiler can't say > at compile-time whether the access can be atomic. But there's a static > constexpr bool called std::atomic<T> ::is_always_lock_free. On the other side I can't believe this because the language says that unaligned accesses have undefined behaviour; so there must be another reason for the distinction between is_lock_free and is_always_lock_free.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-12 14:39 +0100 |
| Message-ID | <qqecn5$o7a$1@news.albasani.net> |
| In reply to | #69718 |
>>> Can anyone tell me whether std::atomic<T>::is_lock_free() isn't static
>>> as well as constexpr? Having it non-static as well as non-constexpr
>>> doesn't make sense for me.
>> Someone on Stack Oveflow told me this: an atomic value might be un-
>> aligned so that access might be not atomic. So the compiler can't say
>> at compile-time whether the access can be atomic. But there's a static
>> constexpr bool called std::atomic<T> ::is_always_lock_free.
> On the other side I can't believe this because the language says that
> unaligned accesses have undefined behaviour; so there must be another
> reason for the distinction between is_lock_free and is_always_lock_free.
Although I was pretty confident that C++ doesn't make the decision
between is_lock_free and is_always_lock_free because of the alignement
I wrote a little program to check this. I've got installed Visual Studio
with compilers for the Windows-platforms for ARMv8-CPUs. And ARMv8 is
able to do unaligned memory-accesses but compare & exchange etc. is
mandated to be aligned. So I thought that when I call is_lock_free on
a pointer to an atomic is_lock_free wouldn't simply return true of for
each atomic but only if the atomic is properly aligned. So I wrote a
little function to check this:
#include <atomic>
#include <cstddef>
bool isLockFreeAtomic( std::atomic<std::uint64_t> *a64 )
{
return a64->is_lock_free();
}
When I compile this with assembly-output I get the following code:
|?isLockFreeAtomic@@YA_NPAU?$atomic@_K@std@@@Z| PROC
movs r0,#1
|$M12|
bx lr
ENDP
So it's like I expected: the runtime-lib doesn't check the pointer.
So there must be another reason why there's a decision between
is_lock_free and is_always_lock_free.
[toc] | [prev] | [next] | [standalone]
| From | Bo Persson <bo@bo-persson.se> |
|---|---|
| Date | 2019-11-12 16:46 +0100 |
| Message-ID | <h302fhFs1t7U1@mid.individual.net> |
| In reply to | #69719 |
On 2019-11-12 at 14:39, Bonita Montero wrote:
>>>> Can anyone tell me whether std::atomic<T>::is_lock_free() isn't static
>>>> as well as constexpr? Having it non-static as well as non-constexpr
>>>> doesn't make sense for me.
>
>>> Someone on Stack Oveflow told me this: an atomic value might be un-
>>> aligned so that access might be not atomic. So the compiler can't say
>>> at compile-time whether the access can be atomic. But there's a static
>>> constexpr bool called std::atomic<T> ::is_always_lock_free.
>
>> On the other side I can't believe this because the language says that
>> unaligned accesses have undefined behaviour; so there must be another
>> reason for the distinction between is_lock_free and is_always_lock_free.
>
> Although I was pretty confident that C++ doesn't make the decision
> between is_lock_free and is_always_lock_free because of the alignement
> I wrote a little program to check this. I've got installed Visual Studio
> with compilers for the Windows-platforms for ARMv8-CPUs. And ARMv8 is
> able to do unaligned memory-accesses but compare & exchange etc. is
> mandated to be aligned. So I thought that when I call is_lock_free on
> a pointer to an atomic is_lock_free wouldn't simply return true of for
> each atomic but only if the atomic is properly aligned. So I wrote a
> little function to check this:
>
> #include <atomic>
> #include <cstddef>
> bool isLockFreeAtomic( std::atomic<std::uint64_t> *a64 )
> {
> return a64->is_lock_free();
> }
>
> When I compile this with assembly-output I get the following code:
>
> |?isLockFreeAtomic@@YA_NPAU?$atomic@_K@std@@@Z| PROC
> movs r0,#1
> |$M12|
> bx lr
> ENDP
>
> So it's like I expected: the runtime-lib doesn't check the pointer.
> So there must be another reason why there's a decision between
> is_lock_free and is_always_lock_free.
It might just be for historic reasons. In C++14 we only have the
function and it is speced:
Returns: True if the object’s operations are lock-free, false otherwise.
It said nothing about whether different objects of the same type always
returned the same value.
In C++17 we also got is_always_lock_free, where *always* is important,
and the function is now supposed to return the same value (says a
non-normative comment...).
Bo Persson
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-12 17:40 +0100 |
| Message-ID | <qqenae$thq$1@news.albasani.net> |
| In reply to | #69720 |
> It might just be for historic reasons. In C++14 we only have the > function and it is speced: > Returns: True if the object’s operations are lock-free, false otherwise. > It said nothing about whether different objects of the same type always > returned the same value. There's no logical reason why they should.
[toc] | [prev] | [next] | [standalone]
| From | Bo Persson <bo@bo-persson.se> |
|---|---|
| Date | 2019-11-12 20:23 +0100 |
| Message-ID | <h30f5hF722U1@mid.individual.net> |
| In reply to | #69722 |
On 2019-11-12 at 17:40, Bonita Montero wrote:
>> It might just be for historic reasons. In C++14 we only have the
>> function and it is speced:
>> Returns: True if the object’s operations are lock-free, false otherwise.
>> It said nothing about whether different objects of the same type
>> always returned the same value.
>
> There's no logical reason why they should.
So therefore we now also have the member is_always_lock_free. :-)
In my previous post I a bit hastily stated that the functions always
return that value, but in reality that is only true if the value *is* true.
When is_always_lock_free is false, the functions just *might* return
true in some cases and false in others.
Just to make it more complicated, there are also macros for some types,
like ATOMIC_INT_LOCK_FREE (which can have the value "sometimes lock
free" :-).
Bo Persson
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-11-12 15:21 -0800 |
| Message-ID | <qqfepc$1vi7$1@gioia.aioe.org> |
| In reply to | #69723 |
On 11/12/2019 11:23 AM, Bo Persson wrote: > On 2019-11-12 at 17:40, Bonita Montero wrote: >>> It might just be for historic reasons. In C++14 we only have the >>> function and it is speced: >>> Returns: True if the object’s operations are lock-free, false otherwise. >>> It said nothing about whether different objects of the same type >>> always returned the same value. >> >> There's no logical reason why they should. > > So therefore we now also have the member is_always_lock_free. :-) > > In my previous post I a bit hastily stated that the functions always > return that value, but in reality that is only true if the value *is* true. > > When is_always_lock_free is false, the functions just *might* return > true in some cases and false in others. > > Just to make it more complicated, there are also macros for some types, > like ATOMIC_INT_LOCK_FREE (which can have the value "sometimes lock > free" :-). Indeed! The atomic types are allowed to be created using locks or even obstruction free constructs: All lock-free is obstruction free, but not all obstruction free is lock-free... ;^)
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-11-14 13:09 -0800 |
| Message-ID | <qqkfr5$15pq$1@gioia.aioe.org> |
| In reply to | #69723 |
On 11/14/2019 1:43 AM, Bonita Montero wrote: >>>> And where's the specialization for a native dwcas-datatype of >>>> atomic<T>? > >>> is_lock_free > >> Read this: >> https://groups.google.com/forum/#!original/lock-free/X3fuuXknQF0/Ho0H1iJgmrQJ >> If the hardware has DWCAS, so does C++11... Either the type is >> lock-free or not. >> The method I used wrt dynamic code was well before C++11. > > C++ has no notion of DCAS; everything is transparent. C++11 can handle DWCAS. However, DCAS is something different. The DW stands for Double Width, so two _adjacent_ words in contiguous memory. DCAS can operate on two non-adjacent words. If its lock free wrt is_lock_free, well, it should be using cmpxchg8b on, say a 32 bit x86. Or, cmpxchg16b on a 64 bit x86. Itanium had the strange cmp8xchg16. These have some bits in cpuid, iirc. https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-isprocessorfeaturepresent
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-13 06:34 +0100 |
| Message-ID | <qqg4kb$mef$1@news.albasani.net> |
| In reply to | #69723 |
> When is_always_lock_free is false, the functions just *might* return > true in some cases and false in others. I see no logical reason why the machine should determine at #runtime if an atomic<T> can do lock-free operations.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-11-13 22:00 -0800 |
| Message-ID | <qqiqir$1bak$3@gioia.aioe.org> |
| In reply to | #70107 |
On 11/12/2019 9:34 PM, Bonita Montero wrote: >> When is_always_lock_free is false, the functions just *might* return >> true in some cases and false in others. > > I see no logical reason why the machine should determine > at #runtime if an atomic<T> can do lock-free operations. Fwiw, I remember creating some dynamic code wrt checking to see if an x86 had DWCAS or not at runtime. It would set a function pointer to the correct function.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-14 07:26 +0100 |
| Message-ID | <qqis2s$u3k$1@news.albasani.net> |
| In reply to | #70125 |
>> I see no logical reason why the machine should determine >> at #runtime if an atomic<T> can do lock-free operations. > Fwiw, I remember creating some dynamic code wrt checking to see if an > x86 had DWCAS or not at runtime. It would set a function pointer to the > correct function. And where's the specialization for a native dwcas-datatype of atomic<T>?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-11-13 22:33 -0800 |
| Message-ID | <qqisfl$1jdf$1@gioia.aioe.org> |
| In reply to | #70126 |
On 11/13/2019 10:26 PM, Bonita Montero wrote: >>> I see no logical reason why the machine should determine >>> at #runtime if an atomic<T> can do lock-free operations. > >> Fwiw, I remember creating some dynamic code wrt checking to see if an >> x86 had DWCAS or not at runtime. It would set a function pointer to >> the correct function. > > And where's the specialization for a native dwcas-datatype of atomic<T>? is_lock_free
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-11-13 22:33 -0800 |
| Message-ID | <qqisgb$1jdf$2@gioia.aioe.org> |
| In reply to | #70127 |
On 11/13/2019 10:33 PM, Chris M. Thomasson wrote: > On 11/13/2019 10:26 PM, Bonita Montero wrote: >>>> I see no logical reason why the machine should determine >>>> at #runtime if an atomic<T> can do lock-free operations. >> >>> Fwiw, I remember creating some dynamic code wrt checking to see if an >>> x86 had DWCAS or not at runtime. It would set a function pointer to >>> the correct function. >> >> And where's the specialization for a native dwcas-datatype of atomic<T>? > > is_lock_free C++11 can handle DWCAS, no problem.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-14 07:51 +0100 |
| Message-ID | <qqith8$ctl$2@news.albasani.net> |
| In reply to | #70128 |
>>> And where's the specialization for a native dwcas-datatype of atomic<T>? >> is_lock_free > C++11 can handle DWCAS, no problem. I'm feeling like talking to Melzzzz.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-14 07:50 +0100 |
| Message-ID | <qqitfk$ctl$1@news.albasani.net> |
| In reply to | #70127 |
>> And where's the specialization for a native dwcas-datatype of atomic<T>? > is_lock_free Look at the above question ...
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-11-13 23:14 -0800 |
| Message-ID | <qqiurv$1uks$1@gioia.aioe.org> |
| In reply to | #70127 |
On 11/13/2019 10:33 PM, Chris M. Thomasson wrote: > On 11/13/2019 10:26 PM, Bonita Montero wrote: >>>> I see no logical reason why the machine should determine >>>> at #runtime if an atomic<T> can do lock-free operations. >> >>> Fwiw, I remember creating some dynamic code wrt checking to see if an >>> x86 had DWCAS or not at runtime. It would set a function pointer to >>> the correct function. >> >> And where's the specialization for a native dwcas-datatype of atomic<T>? > > is_lock_free Read this: https://groups.google.com/forum/#!original/lock-free/X3fuuXknQF0/Ho0H1iJgmrQJ If the hardware has DWCAS, so does C++11... Either the type is lock-free or not. The method I used wrt dynamic code was well before C++11.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-14 10:43 +0100 |
| Message-ID | <qqj7j3$j86$3@news.albasani.net> |
| In reply to | #70132 |
>>> And where's the specialization for a native dwcas-datatype of atomic<T>? >> is_lock_free > Read this: > https://groups.google.com/forum/#!original/lock-free/X3fuuXknQF0/Ho0H1iJgmrQJ > If the hardware has DWCAS, so does C++11... Either the type is lock-free > or not. > The method I used wrt dynamic code was well before C++11. C++ has no notion of DCAS; everything is transparent.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-11-12 15:14 -0800 |
| Message-ID | <qqfech$1t06$1@gioia.aioe.org> |
| In reply to | #69716 |
On 11/12/2019 1:54 AM, Bonita Montero wrote: > Can anyone tell me whether std::atomic<T>::is_lock_free() isn't static > as well as constexpr? Having it non-static as well as non-constexpr > doesn't make sense for me. > Take a deep look at the following macros: https://en.cppreference.com/w/c/atomic/ATOMIC_LOCK_FREE_consts
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-14 13:11 +0100 |
| Message-ID | <qqjg8q$sju$2@news.albasani.net> |
| In reply to | #69724 |
>> Can anyone tell me whether std::atomic<T>::is_lock_free() isn't static >> as well as constexpr? Having it non-static as well as non-constexpr >> doesn't make sense for me. > Take a deep look at the following macros: > https://en.cppreference.com/w/c/atomic/ATOMIC_LOCK_FREE_consts Doesn't help with the question why lock-free-ness of basic atomic -datatypes might be determined at runtime since all these macros are evaluated at compile-time.
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | comp.lang.c++
csiph-web