std::atomic<T>::is_lock_free()

[Bonita Montero]

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.

[Bonita Montero]

> 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.

[Bonita Montero]

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.

[Bonita Montero]

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.

[Bo Persson]

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

[Bonita Montero]

> 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.

[Bo Persson]

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

[Chris M. Thomasson]

Take a deep look at the following macros:

https://en.cppreference.com/w/c/atomic/ATOMIC_LOCK_FREE_consts

[Chris M. Thomasson]

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... ;^)

[Bonita Montero]

> 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.

[Chris M. Thomasson]

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.

[Bonita Montero]

>> 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>?

[Chris M. Thomasson]

is_lock_free

[Chris M. Thomasson]

C++11 can handle DWCAS, no problem.

[Bonita Montero]

>> And where's the specialization for a native dwcas-datatype of atomic<T>?

> is_lock_free

Look at the above question ...

[Bonita Montero]

>>> 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.

[Chris M. Thomasson]

On 11/13/2019 10:33 PM, Chris M. Thomasson wrote:

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.

[Bonita Montero]

>>> 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.

[Öö Tiib]

C++ can only use features that its execution environment lets it to.
There may be difference between what same operating system
provides (in its dynamic runtime library versions). These differences
can be side by side available to same executable on same machine
... read up on "dll hell". Further there may be difference what these
runtime libraries provide to variables of same type. For example it
may depend on how variable of a type is (unavoidably) aligned in
memory if it can be accessed without locks atomically.

[Bonita Montero]

> There may be difference between what same operating system
> provides (in its dynamic runtime library versions). These differences
> can be side by side available to same executable on same machine
> ... read up on "dll hell". Further there may be difference what these
> runtime libraries provide to variables of same type. For example it
> may depend on how variable of a type is (unavoidably) aligned in
> memory if it can be accessed without locks atomically.

Lock-free Atomic operations don't depend on the operating-system,
the dll-hell (weird idea) or the runtime-libraries. And you can be
be sure that the specialized atomics that are lock-free are declared
to be properly aligned at the class-definition.
Do you want to compete with Melzzzz in expertise-unawareness?

[Bonita Montero]

>> 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.

[Öö Tiib]

These were the points raised when C++11 atomics were coined:
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html#DiscussLockFree>
Why don't you go and participate in standardization if you are better
expert than those dimwits in working group 21.

[Bonita Montero]

This paper doesn't say why is_lock_free can be evaluated at runtime.

[Öö Tiib]

Note that universe can not be modified just by typing untruths. :D
That is official paper and it continues to say why lock free query
function was proposed to be dynamic per object for how long it
is archived.

[Bonita Montero]

Quote that statement of the paper.

[Bonita Montero]

> Quote that statement of the paper.

Ok, you're right:
"The proposal provides run-time lock-free query functions rather
than compile-time constants because subsequent implementations of
a platform may upgrade locking operations with lock-free operations,
so it is common for systems to abstract such facilities behind dynamic
libraries, and we wish to leave that possiblility open. Furthermore,
we recommend that implementations without hardware atomic support use
that technique."
But that's rather an abstract and untechnical statement.

[Öö Tiib]

The proposal provides lock-free query functions on individual objects rather than whole types to permit unavoidably misaligned atomic variables without penalizing the performance of aligned atomic variables.

[Bonita Montero]

> The proposal provides lock-free query functions on individual objects rather than whole types to permit unavoidably misaligned atomic variables without penalizing the performance of aligned atomic variables.

That's rather stupid since the language says that access to unaligned
data has an undefined behaviour. And there's not the least necessitiy
in using unaligned atomics.

[Melzzzzz]

Do you know what lock free means?


--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala

[Bonita Montero]

>>> There may be difference between what same operating system
>>> provides (in its dynamic runtime library versions). These differences
>>> can be side by side available to same executable on same machine
>>> ... read up on "dll hell". Further there may be difference what these
>>> runtime libraries provide to variables of same type. For example it
>>> may depend on how variable of a type is (unavoidably) aligned in
>>> memory if it can be accessed without locks atomically.

>> Lock-free Atomic operations don't depend on the operating-system,
>> the dll-hell (weird idea) or the runtime-libraries. And you can be
>> be sure that the specialized atomics that are lock-free are declared
>> to be properly aligned at the class-definition.
>> Do you want to compete with Melzzzz in expertise-unawareness?

> Do you know what lock free means?

You're the last who knows that.

[Chris M. Thomasson]

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

[Chris M. Thomasson]

On 11/14/2019 2:45 AM, Bonita Montero wrote:
>> There may be difference between what same operating system
>> provides (in its dynamic runtime library versions). These differences
>> can be side by side available to same executable on same machine
>> ... read up on "dll hell". Further there may be difference what these
>> runtime libraries provide to variables of same type. For example it
>> may depend on how variable of a type is (unavoidably) aligned in
>> memory if it can be accessed without locks atomically.
>
> Lock-free Atomic operations don't depend on the operating-system,

Are you sure about that? Remember that one can implement a pure std
c++11 atomic lib using semaphores. Windows has some interesting checks
wrt memory violations wrt its lock-free stack. Its all in the OS.

[Chris M. Thomasson]

BM is JG. am 99.98... percent sure....

[Chris M. Thomasson]

You are quite a character. Watch out Melzzzz, the Cruel Puppet BM is
very strange!

https://www.thezorklibrary.com/history/cruel_puppet.html

CRUEL PUPPET

Few creatures are more despised than the cruel puppet, one which uses
its power not for good, evil or profit, but simply to hurt people's
feelings. Staunch monarchs have been reduced to tears by these merciless
shapeshifters; for it attacks by twisting itself into unflattering
caricatures of its opponents, accompanied by jeers, rude noises and
shocking accusations--which include the recital of nightly personal
habits in excruciating detail, accusing its adversary's mother of
shocking improprieties, reminding of weight gain, etc. They have also
been known to practice existential put downs. "You're so ugly you're
probably the creation of an unseen master who is controlling and shaping
the world around you. Nothing is real and nothing you do will have any
lasting effect on those around you. Welcome to the dark night of your
soul" is but one example. More often, however, they just insult your
knees. Insulting the cruel puppet in return is futile, for it feeds off
of them. Straining to ignore these verbal attacks is the only known defense.

Residents of Gurth City were warned during the mid-tenth century to keep
away from the Forest of Youth, as it was known home to cruel puppets.

During the Great Monster Uprising of the Second Age of Magic, cruel
puppets were reported in the following regions: The abandoned Casino of
Port Foozle, The Southern Wastes, The Coast Road near Borphee, Pheebor,
Forest of Youth, Gurth Woodland Trail, the Lost Castle of Y'Syska, Crab
Island, Egreth Castle, The Glass Maze, Bozbarland, Largoneth Castle, and
the G.U.E. Tech Training Grounds in the Ethereal Plane of Atrii. Many
perched in trees and other high and covert corners, raining handfuls of
exploding chestnuts down upon luckless adventurers.

[Chris M. Thomasson]

On 11/14/2019 1:32 PM, Chris M. Thomasson wrote:
> On 11/14/2019 2:45 AM, Bonita Montero wrote:
>>> There may be difference between what same operating system
>>> provides (in its dynamic runtime library versions). These differences
>>> can be side by side available to same executable on same machine
>>> ... read up on "dll hell". Further there may be difference what these
>>> runtime libraries provide to variables of same type. For example it
>>> may depend on how variable of a type is (unavoidably) aligned in
>>> memory if it can be accessed without locks atomically.
>>
>> Lock-free Atomic operations don't depend on the operating-system,

How can you say that? How do you know what the os is doing?

[Chris M. Thomasson]

You are JG, right?

[Bonita Montero]

Tell me of the sense to use non-aligned atomics.

[Bonita Montero]

>> Lock-free Atomic operations don't depend on the operating-system,

^^^^^^^^^^^^^^^^

> Are you sure about that? Remember that one can implement a pure std

> c++11 atomic lib using semaphores. ...

Wat of the underlined wording above don't you unterstand?

[Chris M. Thomasson]

Not sure what that even means. Are you talking about L2 cache alignment
and proper padding? Its used to avoid false sharing.

[Chris M. Thomasson]

Ideally lock-free atomic operations should boil down to pure hardware
instructions. Take a 32 bit x86. The atomic operation of a double word
should be using CMPXCHG8B. However, we cannot know what some operating
system is doing. Like I said, the simple lock-free stack on Windows uses
some funky OS support.

[Scott Lurndal]

Why do you bother with BM? It deliberatly removes attributes so
it's impossible to see who said what to whom.

In any case, unaligned atomics are useless, and many architectures
won't support them (particularly in uncachable memory regions like
those mapped to PCI express bars (and PCI express endpoints -may- support atomic
operations...)).

I suspect that most architectures avoid supporting unaligned atomics
because they might split cache lines which would make it impossible
(or very time consuming) to support atomic semantics for the access.

[Chris M. Thomasson]

On 11/15/2019 1:47 PM, Scott Lurndal wrote:
> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>> On 11/15/2019 12:31 AM, Bonita Montero wrote:
>>>>>> The proposal provides lock-free query functions on individual
>>>>>> objects rather than whole types to permit unavoidably misaligned
>>>>>> atomic variables without penalizing the performance of aligned
>>>>>> atomic variables.
>>>
>>>>> That's rather stupid since the language says that access to unaligned
>>>>> data has an undefined behaviour. And there's not the least necessitiy
>>>>> in using unaligned atomics.
>>>
>>>> You are JG, right?
>>>
>>> Tell me of the sense to use non-aligned atomics.
>>
>> Not sure what that even means. Are you talking about L2 cache alignment
>> and proper padding? Its used to avoid false sharing.
>
> Why do you bother with BM? It deliberatly removes attributes so
> it's impossible to see who said what to whom.

I think BM = JG. Its a sock puppet...

> In any case, unaligned atomics are useless, and many architectures
> won't support them (particularly in uncachable memory regions like
> those mapped to PCI express bars (and PCI express endpoints -may- support atomic
> operations...)).
>
> I suspect that most architectures avoid supporting unaligned atomics
> because they might split cache lines which would make it impossible
> (or very time consuming) to support atomic semantics for the access.
>

Well, I remember abusing unaligned atomics such that a word straddles a
L2 cache line! Well, on x86 this should trigger a system wide bus lock
for legacy reasons. It did something quite interesting. It acted like a
remote memory barrier that makes it possible to implement asymmetric
sync algorithms. There is a mention of it, need to find it. They called
it something like QPI? Humm... Let me do a little search...

[searching]

Found it!

https://blogs.oracle.com/dave/qpi-quiescence

This is very hackish, but does allow for RCU. Also, fwiw, Windows has an
interesting instruction:

https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-flushprocesswritebuffers

That can provide a similar behavior. Iirc, it sends IPIs to an affinity
mask of processors. This can be done in the Kernel with Windows. It
takes a device driver.

[Chris M. Thomasson]

On 11/15/2019 1:47 PM, Scott Lurndal wrote:

> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>> On 11/15/2019 12:31 AM, Bonita Montero wrote:
>>>>>> The proposal provides lock-free query functions on individual
>>>>>> objects rather than whole types to permit unavoidably misaligned
>>>>>> atomic variables without penalizing the performance of aligned
>>>>>> atomic variables.
>>>
>>>>> That's rather stupid since the language says that access to unaligned
>>>>> data has an undefined behaviour. And there's not the least necessitiy
>>>>> in using unaligned atomics.
>>>
>>>> You are JG, right?
>>>
>>> Tell me of the sense to use non-aligned atomics.
>>
>> Not sure what that even means. Are you talking about L2 cache alignment
>> and proper padding? Its used to avoid false sharing.
>
> Why do you bother with BM? It deliberatly removes attributes so
> it's impossible to see who said what to whom.

[...]

Actually, I have asked it to use proper quoting for some time now. Also,
it acts like the following thing:

https://zork.fandom.com/wiki/Cruel_Puppet

Sometimes, it feels like I am casting my pearls before something... ;^o

Might have to stop feeding it.

[Ian Collins]

On 16/11/2019 10:59, Chris M. Thomasson wrote:
>
> Actually, I have asked it to use proper quoting for some time now. Also,
> it acts like the following thing:
>
> https://zork.fandom.com/wiki/Cruel_Puppet
>
> Sometimes, it feels like I am casting my pearls before something... ;^o
>
> Might have to stop feeding it.

Please do!

--
Ian.

[Öö Tiib]

Huh? But it makes sense on hundreds of cases?

You said that paper n2427 by Hans-J. Boehm and Dr. Lawrence Crowl
is rather stupid. So now you tell what you think are most common
(minimum 3 different) use cases for atomic access and similarly
common use cases for __attribute__((packed)) and then tell why
all (minimally 9) combined cases are "rather stupid" to expect
to coincide to same object.

[Bonita Montero]

> You said that paper n2427 by Hans-J. Boehm and Dr. Lawrence Crowl
> is rather stupid. So now you tell what you think are most common
> (minimum 3 different) use cases for atomic access and similarly
> common use cases for __attribute__((packed)) and then tell why
> all (minimally 9) combined cases are "rather stupid" to expect
> to coincide to same object.

Why should I tell that? C++ has no support for unaligned accesses.
And __attribute__((packed)) isn't C++.

[Öö Tiib]

Because otherwise you look like piece of shit.

Standard left alignment up to implementation to define. It even says
that implementation may define it differently for whole objects and
subjects. So ways to let programmer to alter what implementation
defines are yes not part of standard but present in every
implementation worth to mention.

[Bonita Montero]

>> Why should I tell that? C++ has no support for unaligned accesses.
>> And __attribute__((packed)) isn't C++.

> Because otherwise you look like piece of shit.

> Standard left alignment up to implementation to define.

The standard doesn't support unaligned accesses and thereby indirectly
defines that all data-types declared in the way the standard defines
have a proper alignment. So also the atomics have a proper alignment.
So there's no explicit need for the standard to support unaligned
accesses.

[Öö Tiib]

On Saturday, 16 November 2019 18:13:10 UTC+2, Bonita Montero wrote:
> >> Why should I tell that? C++ has no support for unaligned accesses.
> >> And __attribute__((packed)) isn't C++.
>
> > Because otherwise you look like piece of shit.
>
> > Standard left alignment up to implementation to define.
>
> The standard doesn't support

Not in this reality. Standard has fully left it up to implementation
to decide if alignment of say int member in a particular struct is 1
or 2 or 4 or 8 and why.
Seems that you don't know standard and also you don't know any use
cases for packed structs and therefore wiggle pathetically.

[Scott Lurndal]

Yes, that's the "very time consuming" part.

We (3Leaf Systems) designed a chip in the mid 2000s that connected
to the processor via Hypertransport (Opteron) or QPI (Intel) and
extended the processor coherency domain over Infiniband[*] to another
instance of our chip (allowing creation of large shared memory
systems consisting of commodity 1u or 2u rack mount SMP boxes).

One of the national labs was benchmarking the system by pounding on
a spinlock from all 128 cores (across 16 2-socket nodes).

A little known characteristic of AMD and Intel
processors is that if a processor isn't making progress on acquiring
a highly contended cache-line, it will at some point decide to obtain the
system bus lock.

Needless to say, performance was shit (although the test was designed
to show this behavior and was not representative of the labs normal
workloads on the system).

[*] The chip had 2MByte of DRAM caching remote lines, a miss cost about
800 ns round trip (using DDR IB) on the HT systems, and 500ns on QPI (using QDR IB).

[Bonita Montero]

>>>> Why should I tell that? C++ has no support for unaligned accesses.
>>>> And __attribute__((packed)) isn't C++.

>>> Because otherwise you look like piece of shit.

>>> Standard left alignment up to implementation to define.

>> The standard doesn't support

> Not in this reality. Standard has fully left it up to implementation
> to decide if alignment of say int member in a particular struct is 1
> or 2 or 4 or 8 and why.

I didn't say any contrary.

> Seems that you don't know standard and also you don't know any
> use cases for packed structs and therefore wiggle pathetically.

You can't even read what I said.

[Öö Tiib]

You just try to wiggle away from giving 3 examples when packed
structs are most commonly used. Nonsense claims that standard
does not allow implementations to have those packed structs
do not hold. The packed structs (supported by all compilers)
are not violating standard. Compilers do not need to give any
diagnostics when packed structs are used. So pick some other
direction to what to wiggle.

[Bonita Montero]

>>> Seems that you don't know standard and also you don't know any
>>> use cases for packed structs and therefore wiggle pathetically.

>> You can't even read what I said.

> You just try to wiggle away from giving 3 examples when packed
> structs are most commonly used.

They might be used, but packed structures with result in unaligned
members have undefined behaviour. C an C++ knows a natural alignment
for any complete datatype and every datatype must have this align-
ment to be portable.
So you can assume that a conformant implmentation of std:atomic
has an appropriate alignment on std::atomic<T> for any T. So there
is no inherent need to support is_lock_free for alignment-issues
and there must be another good reason because for this is evaluated
at runtime.

> Nonsense claims that standard does not allow implementations
> to have those packed structs do not hold.

The discussion was about the need for is_lock_Free because of any
alignment-issues.

> The packed structs (supported by all compilers) are not violating
> standard.

Of course they do. Accessing a non-aligned variable is not portable.

[Öö Tiib]

On Saturday, 16 November 2019 20:47:13 UTC+2, Bonita Montero wrote:
> >>> Seems that you don't know standard and also you don't know any
> >>> use cases for packed structs and therefore wiggle pathetically.
>
> >> You can't even read what I said.
>
> > You just try to wiggle away from giving 3 examples when packed
> > structs are most commonly used.
>
> They might be used, but packed structures with result in unaligned
> members have undefined behaviour. C an C++ knows a natural alignment
> for any complete datatype and every datatype must have this align-
> ment to be portable.

Nonsense. What is aligned or misaligned is up to compiler
itself to decide. So if compiler itself put a member of struct
into position misaligned for underlying processor then also
compiler has to generate code that makes reads and writes of
that member to behave well defined.

> So you can assume that a conformant implmentation of std:atomic
> has an appropriate alignment on std::atomic<T> for any T. So there
> is no inherent need to support is_lock_free for alignment-issues
> and there must be another good reason because for this is evaluated
> at runtime.

More nonsense. Nothing in standard says that all objects of type
std::atomic<T> are aligned in a way that reads and writes to those
objects can be made lock free. On the contrary. It may be different
for different std::atomic<T> members of same object and different
for same std::atomic<T> member of different objects. Therefore
if you want to know that about concrete object you have to call
is_lock_free() to it to find it out.

>
> > Nonsense claims that standard does not allow implementations
> > to have those packed structs do not hold.
>
> The discussion was about the need for is_lock_Free because of any
> alignment-issues.
>
> > The packed structs (supported by all compilers) are not violating
> > standard.
>
> Of course they do. Accessing a non-aligned variable is not portable.

You now try to break nonsense-meter of mine? :D That is impossible.
Packed structs are quite often used to achieve processor-agnostic,
language-agnostic and operating-system-agnostic bit-layouts of data.
So those are one of tools for having portable data.

[Chris M. Thomasson]

Indeed. A forced unaligned atomic access wrt hacking RCU was amortized
and used on a fairly rare basis. Think along the lines of read-"mostly"
usage patterns. Wrt RCU, we can collect garbage on a per-thread basis,
and when a threads garbage gets over a "threshold", it can decide to
execute a system wide membar, or something else. The asymmetric side of
things is to have a fast side, and a slow side... The fast are the
readers, the slow is the writers. Readers can run full steam ahead, and
do not interfere with writers.

>
> We (3Leaf Systems) designed a chip in the mid 2000s that connected
> to the processor via Hypertransport (Opteron) or QPI (Intel) and
> extended the processor coherency domain over Infiniband[*] to another
> instance of our chip (allowing creation of large shared memory
> systems consisting of commodity 1u or 2u rack mount SMP boxes).
>
> One of the national labs was benchmarking the system by pounding on
> a spinlock from all 128 cores (across 16 2-socket nodes).

YIKES! Hammer time. ;^)

>
> A little known characteristic of AMD and Intel
> processors is that if a processor isn't making progress on acquiring
> a highly contended cache-line, it will at some point decide to obtain the
> system bus lock.
>
> Needless to say, performance was shit (although the test was designed
> to show this behavior and was not representative of the labs normal
> workloads on the system).
>
> [*] The chip had 2MByte of DRAM caching remote lines, a miss cost about
> 800 ns round trip (using DDR IB) on the HT systems, and 500ns on QPI (using QDR IB).
>

Did you try using hash tables just to experiment wrt taking pressure off
of a single lock? Even that does not scale all that great. However, its
better than a single funnel... ;^)

[Scott Lurndal]

The purpose of the test was to see what happened when all cores contended
for the same line (running slow is expected, crashing (which we didn't) isn't).

Actual lab codes were much better structured from a parallelism standpoint.

[Chris M. Thomasson]

It should not crash, slowing to a crawl is expected.

[Bonita Montero]

>> They might be used, but packed structures with result in unaligned
>> members have undefined behaviour. C an C++ knows a natural alignment
>> for any complete datatype and every datatype must have this align-
>> ment to be portable.

> Nonsense. What is aligned or misaligned is up to compiler

> itself to decide. ...

We're not talking about certain implementations but the language.
And unaligned accesses simply aren't portable.

>> So you can assume that a conformant implmentation of std:atomic
>> has an appropriate alignment on std::atomic<T> for any T. So there
>> is no inherent need to support is_lock_free for alignment-issues
>> and there must be another good reason because for this is evaluated
>> at runtime.

> More nonsense. Nothing in standard says that all objects of type
> std::atomic<T> are aligned in a way that reads and writes to those
> objects can be made lock free.

You can't read. I did say:
1. All complete types have a natural alignment.
2. std::atomic<T> thereby has also a natural alignment.
3. is_lock_free couldn't be dynamic because of runtime alignment
properties because C++ doesn't support unaligned acceses anyway.

[Öö Tiib]

On Sunday, 17 November 2019 10:17:23 UTC+2, Bonita Montero wrote:
> >> They might be used, but packed structures with result in unaligned
> >> members have undefined behaviour. C an C++ knows a natural alignment
> >> for any complete datatype and every datatype must have this align-
> >> ment to be portable.
>
> > Nonsense. What is aligned or misaligned is up to compiler
> > itself to decide. ...
>
> We're not talking about certain implementations but the language.
> And unaligned accesses simply aren't portable.

I wasn't tslking about concrete compiler. Standard is specification
of C++ compilers and I was writing what standard allows and requires
conforming compilers to do. The compilers that did not do what
standard requires have gradually lost their market share.

> >> So you can assume that a conformant implmentation of std:atomic
> >> has an appropriate alignment on std::atomic<T> for any T. So there
> >> is no inherent need to support is_lock_free for alignment-issues
> >> and there must be another good reason because for this is evaluated
> >> at runtime.
>
> > More nonsense. Nothing in standard says that all objects of type
> > std::atomic<T> are aligned in a way that reads and writes to those
> > objects can be made lock free.
>
> You can't read. I did say:
> 1. All complete types have a natural alignment.
> 2. std::atomic<T> thereby has also a natural alignment.
> 3. is_lock_free couldn't be dynamic because of runtime alignment
> properties because C++ doesn't support unaligned acceses anyway.

I understand very well what you write. It is just wrong.
That "natural alignment" does not exist in C++. Quote from where you
manufactured that misconception? Bald, groundless and wrong assertion
in 1. is making also conclusions from it in 2. and 3. wrong and whole
chain of your logic nonsense.

[Bonita Montero]

>> 1. All complete types have a natural alignment.
>> 2. std::atomic<T> thereby has also a natural alignment.
>> 3. is_lock_free couldn't be dynamic because of runtime alignment
>> properties because C++ doesn't support unaligned acceses anyway.

> I understand very well what you write. It is just wrong.
> That "natural alignment" does not exist in C++.

The implementation-defined natural alignment can be determined with
alignof(). If you write your code so that it will satisfy this alignment
on one platform and not another it is not portable. So each platform
knows its own alignment-requirements and these are also maintained for
the atomic-types. As long as you use proper alignment for your atomics
there coudln't be any alignement-issues. So there's no need for the
standad to mandate support for unaligned atomics through is_lock_free.

[Öö Tiib]

On Sunday, 17 November 2019 12:23:58 UTC+2, Bonita Montero wrote:
> >> 1. All complete types have a natural alignment.
> >> 2. std::atomic<T> thereby has also a natural alignment.
> >> 3. is_lock_free couldn't be dynamic because of runtime alignment
> >> properties because C++ doesn't support unaligned acceses anyway.
>
> > I understand very well what you write. It is just wrong.
> > That "natural alignment" does not exist in C++.
>
> The implementation-defined natural alignment can be determined with
> alignof().

Then read up on alignof in [basic.align]. It is returning alignment
requirement for complete object (and not for subobject).

> If you write your code so that it will satisfy this alignment
> on one platform and not another it is not portable.

Sure, I (as programmer) may not start life-time of whole object
of type T in buffer that is more weakly aligned than alignof(T)
requires.

> So each platform
> knows its own alignment-requirements and these are also maintained for
> the atomic-types.

You are mixing up. The alignof(T) is telling what it is requiring
from programmers. It is not promising that subobjects of type T of
composite objects are aligned by alignof(T).

> As long as you use proper alignment for your atomics
> there coudln't be any alignement-issues. So there's no need for the
> standad to mandate support for unaligned atomics through is_lock_free.

And here it is totally unclear who you address as "you". Are you
addressing programmers, compilers, standards or whole reality that
does not behave by your silly misconceptions?

[Bonita Montero]

>> The implementation-defined natural alignment can be determined with
>> alignof().

> Then read up on alignof in [basic.align]. It is returning alignment
> requirement for complete object (and not for subobject).

I didn't talk about subobjects.

>> So each platform
>> knows its own alignment-requirements and these are also maintained for
>> the atomic-types.

> You are mixing up. The alignof(T) is telling what it is requiring
> from programmers. It is not promising that subobjects of type T of
> composite objects are aligned by alignof(T).

Of course the compiler meets the requirements it also imposes on the
programmer.

[Öö Tiib]

On Sunday, 17 November 2019 15:20:21 UTC+2, Bonita Montero wrote:
> >> The implementation-defined natural alignment can be determined with
> >> alignof().
>
> > Then read up on alignof in [basic.align]. It is returning alignment
> > requirement for complete object (and not for subobject).
>
> I didn't talk about subobjects.

Indeed why you wiggle away from those for whole week?
Where it is written that atomic<T> is unsuitable to be type of subobject
of other object?

>
> >> So each platform
> >> knows its own alignment-requirements and these are also maintained for
> >> the atomic-types.
>
> > You are mixing up. The alignof(T) is telling what it is requiring
> > from programmers. It is not promising that subobjects of type T of
> > composite objects are aligned by alignof(T).
>
> Of course the compiler meets the requirements it also imposes on the
> programmer.

Standard explicitly tells that the subobjects might be aligned
differently than whole objects and now you say that these "of course"
are required to be aligned by alignof and may not be aligned
differently? :D

I think you are just pretending to be so utterly bone-headed so I give
up attempts of teaching you.

[Bonita Montero]

>> I didn't talk about subobjects.

> Indeed why you wiggle away from those for whole week?

That's what I wrote and where you responoded with subobjects-whatever:

The implementation-defined natural alignment can be determined with

alignof(). If you write your code so that it will satisfy this alignment
on one platform and not another it is not portable. So each platform

knows its own alignment-requirements and these are also maintained for

the atomic-types. As long as you use proper alignment for your atomics

there coudln't be any alignement-issues. So there's no need for the
standad to mandate support for unaligned atomics through is_lock_free.

Where did I talk about subobjects there?

> Where it is written that atomic<T> is unsuitable to be type of subobject
> of other object?

Quote where Is said this.

>> Of course the compiler meets the requirements it also imposes on the
>> programmer.

> Standard explicitly tells that the subobjects might be aligned
> differently than whole objects and now you say that these "of course"
> are required to be aligned by alignof and may not be aligned
> differently? :D

The standard says that all objects of complete types have a poper
alignment.

[Bonita Montero]

> Nonsense. What is aligned or misaligned is up to compiler
> itself to decide.

Wrong. If you pack your members tighter than alignof(membertype) allows
this is not conforming.

[James Kuyper]

On 11/16/19 9:40 PM, Chris M. Thomasson wrote:
> On 11/16/2019 2:13 PM, Scott Lurndal wrote:

...
>> ... running slow is expected, crashing ... isn't).
...

> It should not crash, slowing to a crawl is expected.

You just said the same thing, with slightly different wording. Your point?

[Chris M. Thomasson]

My point is that hammering a single mutex should not crash the system.
It will most likely slow it to a crawl. Not start crashing processes
left and right...

[Chris M. Thomasson]

Well, the processes will be working, just going really, really slow. I
hope its not like a slug hiking up a mountain of salt.

[Chris M. Thomasson]

Wrt the work I did wrt straddling cache lines, well, it was all in
assembly language. Pre C++11.

[Bonita Montero]

>> Wrong. If you pack your members tighter than alignof(membertype) allows
>> this is not conforming.

> Wrt the work I did wrt straddling cache lines, well, it was all in
> assembly language. Pre C++11.

>ou have the gift of contributing continuously to things that
have nothing to do with the topic.

[Öö Tiib]

That is a bald and groundless assertion.

[Bonita Montero]

>>> Nonsense. What is aligned or misaligned is up to compiler
>>> itself to decide.

>> Wrong. If you pack your members tighter than alignof(membertype)
>> allows this is not conforming.

> That is a bald and groundless assertion.

"Object types have alignment requirements (6.9.1, 6.9.2) which place
restrictions on the addresses at which an object of that type may be
allocated. ...
The result of the alignof operator reflects the alignment requirement
of the type in the complete-object case."

So if you pack your data tighter than the alignment-requirements
allow, this is not conforming.

[Öö Tiib]

On Sunday, 17 November 2019 16:49:59 UTC+2, Bonita Montero wrote:
>
> The standard says that all objects of complete types have a poper
> alignment.

That is bald, groundless and nonsensical assertion.
All objects *must* have complete types in C++ program:
"A program is ill-formed if the definition of any object gives
the object an incomplete type."

[Bonita Montero]

do you want to do pettifoggery while having lost in the actual
discussion?

[Öö Tiib]

On Monday, 18 November 2019 08:52:27 UTC+2, Bonita Montero wrote:
> >>> Nonsense. What is aligned or misaligned is up to compiler
> >>> itself to decide.
>
> >> Wrong. If you pack your members tighter than alignof(membertype)
> >> allows this is not conforming.
>
> > That is a bald and groundless assertion.
>
> "Object types have alignment requirements (6.9.1, 6.9.2) which place
> restrictions on the addresses at which an object of that type may be
> allocated. ...

...
The alignment required for a type might be different when it is used
as the type of a complete object and when it is used as the type of
a subobject.

...

> The result of the alignof operator reflects the alignment requirement
> of the type in the complete-object case."
>
> So if you pack your data tighter than the alignment-requirements
> allow, this is not conforming.

Members are subobjects not complete objects.
"Objects can contain other objects, called /subobjects/. A subobject
can be a member subobject, a baseclass subobject, or an array element."

[Bonita Montero]

>> "Object types have alignment requirements (6.9.1, 6.9.2) which place
>> restrictions on the addresses at which an object of that type may be
>> allocated. ...

> ...
> The alignment required for a type might be different when it is used
> as the type of a complete object and when it is used as the type of
> a subobject.
> ...

Since you can't get the alignment-requiremen of both with the alignof
-operator I didn't say any different.

>> So if you pack your data tighter than the alignment-requirements
>> allow, this is not conforming.

> Members are subobjects not complete objects.

That's pettifogging.

[Öö Tiib]

On Monday, 18 November 2019 09:10:46 UTC+2, Bonita Montero wrote:
> >> "Object types have alignment requirements (6.9.1, 6.9.2) which place
> >> restrictions on the addresses at which an object of that type may be
> >> allocated. ...
>
> > ...
> > The alignment required for a type might be different when it is used
> > as the type of a complete object and when it is used as the type of
> > a subobject.
> > ...
>
> Since you can't get the alignment-requiremen of both with the alignof
> -operator I didn't say any different.

No, you can't you quoted and now erased it back. Restoring:

On Monday, 18 November 2019 08:52:27 UTC+2, Bonita Montero wrote:
> >> The result of the alignof operator reflects the alignment requirement
> >> of the type in the complete-object case.

I have written it whole week.

> >> So if you pack your data tighter than the alignment-requirements
> >> allow, this is not conforming.
>
> > Members are subobjects not complete objects.
>
> That's pettifogging.

You think that you can change what standard says by erasing attributions
and context in Usenet post? :D

[Ian Collins]

On 18/11/2019 20:23, Öö Tiib wrote:

>
> You think that you can change what standard says by erasing attributions
> and context in Usenet post? :D
>

What else did you expect?

--
Ian.

[James Kuyper]

On 11/17/19 11:59 PM, Chris M. Thomasson wrote:
> On 11/17/2019 3:39 PM, James Kuyper wrote:
>> On 11/16/19 9:40 PM, Chris M. Thomasson wrote:
>>> On 11/16/2019 2:13 PM, Scott Lurndal wrote:
>> ...
>>>> ... running slow is expected, crashing ... isn't).
>> ...
>>> It should not crash, slowing to a crawl is expected.
>>
>> You just said the same thing, with slightly different wording. Your point?
>>
>
> My point is that hammering a single mutex should not crash the system.

But, Scott already said that a crashing was not expected, so why the "me
too" post?

[Chris M. Thomasson]

Habit? Sorry.

[Tim Rentsch]

Not counting the misspelling of proper, there is nothing nonsensical
about it. Furthermore although the C++ standard doesn't use those
exact words, it does imply that the statement is true.

Incidentally, I think the word "bald" doesn't mean what you think it
means. The statement "the sun is shining today" could accurately,
even if perhaps confusingly, be termed a "bald statement".

[Tim Rentsch]

Tiib <oot...@hot.ee> writes:

> On Monday, 18 November 2019 08:52:27 UTC+2, Bonita Montero wrote:
>
>>>>> Nonsense. What is aligned or misaligned is up to compiler
>>>>> itself to decide.
>>>>
>>>> Wrong. If you pack your members tighter than alignof(membertype)
>>>> allows this is not conforming.
>>>
>>> That is a bald and groundless assertion.
>>
>> "Object types have alignment requirements (6.9.1, 6.9.2) which place
>> restrictions on the addresses at which an object of that type may be
>> allocated. ...
>
> ...
> The alignment required for a type might be different when it is used
> as the type of a complete object and when it is used as the type of
> a subobject.
> ...

No it cannot. Refer to n4659, section 6.11, paragraph 1. Note
in particular the last sentence, which says in part (with my
emphasis added):

An object type imposes an alignment requirement on EVERY
OBJECT of that type

There is no provision for the alignment varying according to
whether the object is a complete object or a subobject.

[Öö Tiib]

On Friday, 29 November 2019 01:39:26 UTC+2, Tim Rentsch wrote:

> Öö Tiib <oot...@hot.ee> writes:
>
> > On Sunday, 17 November 2019 16:49:59 UTC+2, Bonita Montero wrote:
> >
> >> The standard says that all objects of complete types have a poper
> >> alignment.
> >
> > That is bald, groundless and nonsensical assertion.
> > All objects *must* have complete types in C++ program:
> > "A program is ill-formed if the definition of any object gives
> > the object an incomplete type."
>
> Not counting the misspelling of proper, there is nothing nonsensical
> about it. Furthermore although the C++ standard doesn't use those
> exact words, it does imply that the statement is true.

Nonsensical is to assert that standard says something specially about
properties of objects of complete types when these are the only kind
of objects that may exist in well-formed program.

If you mean (leaving the nonsense aside) that "all objects must have
proper alignment" is said by standard in some other wording then feel
free to quote, I have found it not.

> Incidentally, I think the word "bald" doesn't mean what you think it
> means. The statement "the sun is shining today" could accurately,
> even if perhaps confusingly, be termed a "bald statement".

I used "bald assertion" in sense of "a statement used without proof
or evidence of truth". Wikipedia claims it is used in that sense
about marketing statements ... I think Bonita uses such statements
just to post something.

[Öö Tiib]

Very next paragraph #2 says that:

[Tim Rentsch]

Tiib writes:

> On Friday, 29 November 2019 01:39:26 UTC+2, Tim Rentsch wrote:
>

>> <<D6 F6 [05b6]>> Tiib <oot...@hot.ee> writes:
>>
>>> On Sunday, 17 November 2019 16:49:59 UTC+2, Bonita Montero wrote:
>>>
>>>> The standard says that all objects of complete types have a poper
>>>> alignment.
>>>
>>> That is bald, groundless and nonsensical assertion.
>>> All objects *must* have complete types in C++ program:
>>> "A program is ill-formed if the definition of any object gives
>>> the object an incomplete type."
>>
>> Not counting the misspelling of proper, there is nothing nonsensical
>> about it. Furthermore although the C++ standard doesn't use those
>> exact words, it does imply that the statement is true.
>
> Nonsensical is to assert that standard says something specially about
> properties of objects of complete types when these are the only kind
> of objects that may exist in well-formed program.

I think you misunderstand the English word nonsensical. A
statement can be unlikely, silly, or ridiculous, but none
of those make it nonsensical. In fact to say a statement
is unlikely more or less automatically implies it is sensical.

> If you mean (leaving the nonsense aside) that "all objects must have
> proper alignment" is said by standard in some other wording then feel
> free to quote, I have found it not.

I mean I find the statement consistent with what the standard
does say.

>> Incidentally, I think the word "bald" doesn't mean what you think it
>> means. The statement "the sun is shining today" could accurately,
>> even if perhaps confusingly, be termed a "bald statement".
>
> I used "bald assertion" in sense of "a statement used without proof
> or evidence of truth". Wikipedia claims it is used in that sense

> about marketing statements ... [...]

Despite what Wikipedia may say, that's isn't what the word means.
I recommend, especially for people for whom English is not their
first language, consulting a dictionary (or better, more than one)
whenever there is any question about what a word means or whether
a particular word is a good choice in a particular situation. I
routinely consult dictionaries when questions like this come up
(yes, even though English is my first language).

[Öö Tiib]

I can communicate in 4 languages and so am convinced that words
mean nothing in essence. Word may be used in one meaning in one
language in totally different meaning in other language and never
used in any meaning in third language. Meaning is what people
wanted to express with those.
Online English encyclopedia just documents with cites that certain
words are used by certain people to express something and so these
words have that meaning. In C++ standard these words are not used
to mean anything and so can not cause confusion with slang of C++.

[Tim Rentsch]

So it does. Interesting.

(It happens that in the document I consulted, these two paragraphs
were split by a page boundary, which makes the second paragraph
easy to miss. It would be better to have the two conflicting
statements be in a single paragraph.)

I note that the example relies on virtual base classes. This
explains why the special case is there. ISTM that having the two
cases be different is poorly thought out, as it makes the notion
of alignment be almost meaningless. But, that's C++ for ya.

[Tim Rentsch]

Tiib writes:

> On Saturday, 11 January 2020 08:48:50 UTC+2, Tim Rentsch wrote:

[...]

>> I recommend, especially for people for whom English is not their
>> first language, consulting a dictionary (or better, more than one)
>> whenever there is any question about what a word means or whether
>> a particular word is a good choice in a particular situation. I
>> routinely consult dictionaries when questions like this come up
>> (yes, even though English is my first language).
>
> I can communicate in 4 languages and so am convinced that words
> mean nothing in essence. Word may be used in one meaning in one
> language in totally different meaning in other language and never
> used in any meaning in third language. Meaning is what people
> wanted to express with those.
> Online English encyclopedia just documents with cites that certain
> words are used by certain people to express something and so these
> words have that meaning. In C++ standard these words are not used
> to mean anything and so can not cause confusion with slang of C++.

When your aim is to communicate with people while speaking (or
writing) English, it's almost always better to use words in the
way that they are likely to be most commonly understood. Using
dictionaries is good for this purpose, precisely because it is
widely accepted (at least in English speaking cultures) that they
provide good and fairly reliably authoritative information. In
short, using dictionaries is good because everyone knows to
consult them.

[Öö Tiib]

I usually do not communicate with purpose of using English.
However I checked couple dictionaries and figured out that
"bald" has roughly two meanings:
1: bare, barren, naked, hairless, having no covering.
2: simple, unadorned, blunt.
So I feel that "bald assertion" carries what I meant.
So it makes me unsure about what you complain.

[Tim Rentsch]

Because I think the phrase doesn't convey the meaning you want
to convey. Or to say that another way, what you think the
phrase says is not how many or most people will read it.

(Incidentally, I wouldn't call my comment a complaint, but
that isn't important, just saying fyi.)

[James Kuyper]

On Tuesday, January 21, 2020 at 5:01:26 AM UTC-5, Tim Rentsch wrote:
> 嘱 Tiib <oot...@hot.ee> writes:
...

> > However I checked couple dictionaries and figured out that
> > "bald" has roughly two meanings:
> > 1: bare, barren, naked, hairless, having no covering.
> > 2: simple, unadorned, blunt.
> > So I feel that "bald assertion" carries what I meant.
> > So it makes me unsure about what you complain.
>
> Because I think the phrase doesn't convey the meaning you want
> to convey. Or to say that another way, what you think the
> phrase says is not how many or most people will read it.

123456789012345678901234567890123456789012345678901234567890123456789012
As Öö Tiib has already mentioned, Wikipedia says that "bald assertion"
means a statement used "without proof or evidence of truth". Wiktionary
<https://en.wiktionary.org/wiki/bald> gives two meanings for bald that
specifically apply to statements: meaning #4 is "Unembellished", and
meaning #5 is "Without evidence or support being provided.". Meaning #5
can be seen as a special case of meaning #4 - the missing embellishments
include the evidence and support.
When I do a general Google search for "bald assertion", all of the top
hits support either meaning #4 or #5.
In 56 years of reading English, I can't remember ever having read a use
of "bald assertion" that didn't match meaning #5. I don't remember it
ever being used to point out the lack of any kind of embellishment other
than the lack of a supporting argument.

So what is it that you claim is the correct meaning of the phrase, one
that you don't think he meant when he used that phrase?