Discussion:
"Safe C++ is A new Proposal to Make C++ Memory-Safe"
(too old to reply)
Lynn McGuire
2024-10-09 01:40:38 UTC
Permalink
"Safe C++ is A new Proposal to Make C++ Memory-Safe"
https://www.infoq.com/news/2024/10/safe-cpp-proposal/

"The goal of the Safe C++ proposal is extending C++ by defining a
superset of the language that can be used to write code with the strong
safety guarantees similarly to code written in Rust. The key to its
approach is introducing a new safe context where only a rigorously safe
subset of C++ is allowed."

"The Safe C++ proposal, set forth by Sean Baxter and Christian Mazakas,
originates from the growing awareness that C++ memory unsafety lies at
the root of a large part of vulnerabilities and memory exploits. The
only existing safe language, say Baxter and Mazakas, is Rust, but their
design differences limit interoperability, thus making it hard to
migrate from one language to the other. For example, Rust lacks function
overloading, templates, inheritance, and exceptions, while C++ lacks
traits, relocation, and borrow checking."

Lynn
Michael S
2024-10-09 11:14:55 UTC
Permalink
On Tue, 8 Oct 2024 20:40:38 -0500
Post by Lynn McGuire
"Safe C++ is A new Proposal to Make C++ Memory-Safe"
https://www.infoq.com/news/2024/10/safe-cpp-proposal/
"The goal of the Safe C++ proposal is extending C++ by defining a
superset of the language that can be used to write code with the
strong safety guarantees similarly to code written in Rust. The key
to its approach is introducing a new safe context where only a
rigorously safe subset of C++ is allowed."
"The Safe C++ proposal, set forth by Sean Baxter and Christian
Mazakas, originates from the growing awareness that C++ memory
unsafety lies at the root of a large part of vulnerabilities and
memory exploits. The only existing safe language, say Baxter and
Mazakas, is Rust,
Journalists are so journalists! Even when, like Sergio De Simone, they
claim that they are software engineers.

Of course, Baxter and Mazakas never said anything like that. Their
statement is much more reasonable: "There’s only one popular systems
level/non-garbage collected language that provides rigorous memory
safety. That’s the Rust language."
I am not sure that I agree with Baxter and Mazakas, but at least
their statement is not as obviously and blatantly wrong as it sound in
"translation" of De Simone.
Post by Lynn McGuire
but their design differences limit
interoperability, thus making it hard to migrate from one language to
the other. For example, Rust lacks function overloading, templates,
inheritance, and exceptions, while C++ lacks traits, relocation, and
borrow checking."
Lynn
Lynn McGuire
2024-10-09 20:02:54 UTC
Permalink
Post by Lynn McGuire
"Safe C++ is A new Proposal to Make C++ Memory-Safe"
   https://www.infoq.com/news/2024/10/safe-cpp-proposal/
"The goal of the Safe C++ proposal is extending C++ by defining a
superset of the language that can be used to write code with the strong
safety guarantees similarly to code written in Rust. The key to its
approach is introducing a new safe context where only a rigorously safe
subset of C++ is allowed."
"The Safe C++ proposal, set forth by Sean Baxter and Christian Mazakas,
originates from the growing awareness that C++ memory unsafety lies at
the root of a large part of vulnerabilities and memory exploits. The
only existing safe language, say Baxter and Mazakas, is Rust, but their
design differences limit interoperability, thus making it hard to
migrate from one language to the other. For example, Rust lacks function
overloading, templates, inheritance, and exceptions, while C++ lacks
traits, relocation, and borrow checking."
Lynn
And what the heck is relocation, traits, and borrow checking ?

Lynn
Michael S
2024-10-09 20:46:05 UTC
Permalink
On Wed, 9 Oct 2024 15:02:54 -0500
Post by Lynn McGuire
Post by Lynn McGuire
"Safe C++ is A new Proposal to Make C++ Memory-Safe"
   https://www.infoq.com/news/2024/10/safe-cpp-proposal/
"The goal of the Safe C++ proposal is extending C++ by defining a
superset of the language that can be used to write code with the
strong safety guarantees similarly to code written in Rust. The key
to its approach is introducing a new safe context where only a
rigorously safe subset of C++ is allowed."
"The Safe C++ proposal, set forth by Sean Baxter and Christian
Mazakas, originates from the growing awareness that C++ memory
unsafety lies at the root of a large part of vulnerabilities and
memory exploits. The only existing safe language, say Baxter and
Mazakas, is Rust, but their design differences limit
interoperability, thus making it hard to migrate from one language
to the other. For example, Rust lacks function overloading,
templates, inheritance, and exceptions, while C++ lacks traits,
relocation, and borrow checking."
Lynn
And what the heck is relocation, traits, and borrow checking ?
Lynn
Traits and borrow checking can't be explained in few words, nor in few
dozens of words.
Ownership model+borrow checker happens to be the main feature that
distinguishes the Rust from the Rest.

'Relocation' does not appear to be an established Rust term.
It seems that Sean Baxter and Christian Mazakas use word 'relocation'
to describe a mechanism use in Rust by default when object that
contains embedded pointers or is of variable size is assigned to
another object. Rust docs call it 'move'.
M***@DastartdlyHQ.org
2024-10-10 08:34:55 UTC
Permalink
On Wed, 9 Oct 2024 23:46:05 +0300
Post by Michael S
On Wed, 9 Oct 2024 15:02:54 -0500
Post by Lynn McGuire
And what the heck is relocation, traits, and borrow checking ?
=20
Lynn
=20
Traits and borrow checking can't be explained in few words, nor in few
dozens of words.
Borrow checking is just a fancy way of compile time checking a pointer/object
will still be valid after being used previously. Eg: If C had borrow checking
the compiler would error at the printf().

void func(char **ptr)
{
*ptr = NULL;
}


int main()
{
char *ptr = "hello";
func(&ptr);
printf("%c\n",*ptr);
return 0;
}
Michael S
2024-10-10 09:51:57 UTC
Permalink
On Thu, 10 Oct 2024 08:34:55 -0000 (UTC)
Post by M***@DastartdlyHQ.org
On Wed, 9 Oct 2024 23:46:05 +0300
Post by Michael S
On Wed, 9 Oct 2024 15:02:54 -0500
Post by Lynn McGuire
And what the heck is relocation, traits, and borrow checking ?
=20
Lynn
=20
Traits and borrow checking can't be explained in few words, nor in
few dozens of words.
Borrow checking is just a fancy way of compile time checking a
If C had borrow checking the compiler would error at the printf().
void func(char **ptr)
{
*ptr = NULL;
}
int main()
{
char *ptr = "hello";
func(&ptr);
printf("%c\n",*ptr);
return 0;
}
Do you think that your explanation is sufficient for Lynn McGuire?
Consider that he probably doesn't know what Rust people have in mind
when they talk about ownership. And you can be sure that he doesn't know
the rusty meaning of 'borrow'.
Even I am not 100% sure that I understand the later, although it seem
to me that in their dialect 'borrow' means 'make a reference'.
M***@DastartdlyHQ.org
2024-10-10 10:20:07 UTC
Permalink
On Thu, 10 Oct 2024 12:51:57 +0300
Post by Michael S
On Thu, 10 Oct 2024 08:34:55 -0000 (UTC)
Post by M***@DastartdlyHQ.org
On Wed, 9 Oct 2024 23:46:05 +0300
Post by Michael S
On Wed, 9 Oct 2024 15:02:54 -0500
Post by Lynn McGuire
And what the heck is relocation, traits, and borrow checking ?
=20
Lynn
=20
Traits and borrow checking can't be explained in few words, nor in
few dozens of words.
Borrow checking is just a fancy way of compile time checking a
If C had borrow checking the compiler would error at the printf().
void func(char **ptr)
{
*ptr = NULL;
}
int main()
{
char *ptr = "hello";
func(&ptr);
printf("%c\n",*ptr);
return 0;
}
Do you think that your explanation is sufficient for Lynn McGuire?
No idea.
Post by Michael S
Consider that he probably doesn't know what Rust people have in mind
when they talk about ownership. And you can be sure that he doesn't know
the rusty meaning of 'borrow'.
Even I am not 100% sure that I understand the later, although it seem
to me that in their dialect 'borrow' means 'make a reference'.
I think its just their way of checking if something could have been altered
before use in a way that might crash the program or introduce bugs.
Michael S
2024-10-10 10:44:59 UTC
Permalink
On Thu, 10 Oct 2024 10:20:07 -0000 (UTC)
Post by M***@DastartdlyHQ.org
On Thu, 10 Oct 2024 12:51:57 +0300
Post by Michael S
On Thu, 10 Oct 2024 08:34:55 -0000 (UTC)
Post by M***@DastartdlyHQ.org
On Wed, 9 Oct 2024 23:46:05 +0300
Post by Michael S
On Wed, 9 Oct 2024 15:02:54 -0500
Post by Lynn McGuire
And what the heck is relocation, traits, and borrow checking ?
=20
Lynn
=20
Traits and borrow checking can't be explained in few words, nor in
few dozens of words.
Borrow checking is just a fancy way of compile time checking a
If C had borrow checking the compiler would error at the printf().
void func(char **ptr)
{
*ptr = NULL;
}
int main()
{
char *ptr = "hello";
func(&ptr);
printf("%c\n",*ptr);
return 0;
}
Do you think that your explanation is sufficient for Lynn McGuire?
No idea.
Post by Michael S
Consider that he probably doesn't know what Rust people have in mind
when they talk about ownership. And you can be sure that he doesn't
know the rusty meaning of 'borrow'.
Even I am not 100% sure that I understand the later, although it seem
to me that in their dialect 'borrow' means 'make a reference'.
I think its just their way of checking if something could have been
altered before use in a way that might crash the program or introduce
bugs.
Now you're talking about meaning of 'borrow checker'.
Before we go that far we have to dig up the meaning of 'borrow'.
M***@DastartdlyHQ.org
2024-10-10 10:50:05 UTC
Permalink
On Thu, 10 Oct 2024 13:44:59 +0300
Post by Michael S
On Thu, 10 Oct 2024 10:20:07 -0000 (UTC)
Post by M***@DastartdlyHQ.org
I think its just their way of checking if something could have been
altered before use in a way that might crash the program or introduce
bugs.
Now you're talking about meaning of 'borrow checker'.
Before we go that far we have to dig up the meaning of 'borrow'.
Since when do programming language keywords always mean the exact same as
the english equivalent? Last time I looked "for" didn't mean "loop" in english.

Frankly borrow-checking can mean whatever they want it to mean this week, but
in general its what I said above.
Michael S
2024-10-10 11:10:47 UTC
Permalink
On Thu, 10 Oct 2024 10:50:05 -0000 (UTC)
Post by M***@DastartdlyHQ.org
On Thu, 10 Oct 2024 13:44:59 +0300
Post by Michael S
On Thu, 10 Oct 2024 10:20:07 -0000 (UTC)
Post by M***@DastartdlyHQ.org
I think its just their way of checking if something could have been
altered before use in a way that might crash the program or
introduce bugs.
Now you're talking about meaning of 'borrow checker'.
Before we go that far we have to dig up the meaning of 'borrow'.
Since when do programming language keywords always mean the exact
same as the english equivalent? Last time I looked "for" didn't mean
"loop" in english.
Well, I don't know how it feels for native English speakers, but for me
meaning of 'loop' in programming is not equivalent to its meaning in
the rest of English language.
Post by M***@DastartdlyHQ.org
Frankly borrow-checking can mean whatever they want it to mean this
week, but in general its what I said above.
Neither 'borrow' nor 'borrow checker' are Rust keywords. They are
abstract (more or less) concepts used in Rust manuals. And it seems
logical that it would be easier to explain the later if we explain the
former first.
M***@DastartdlyHQ.org
2024-10-10 13:11:24 UTC
Permalink
On Thu, 10 Oct 2024 14:10:47 +0300
Post by Michael S
On Thu, 10 Oct 2024 10:50:05 -0000 (UTC)
Post by M***@DastartdlyHQ.org
On Thu, 10 Oct 2024 13:44:59 +0300
Post by Michael S
On Thu, 10 Oct 2024 10:20:07 -0000 (UTC)
Post by M***@DastartdlyHQ.org
I think its just their way of checking if something could have been
altered before use in a way that might crash the program or
introduce bugs.
Now you're talking about meaning of 'borrow checker'.
Before we go that far we have to dig up the meaning of 'borrow'.
Since when do programming language keywords always mean the exact
same as the english equivalent? Last time I looked "for" didn't mean
"loop" in english.
Well, I don't know how it feels for native English speakers, but for me
meaning of 'loop' in programming is not equivalent to its meaning in
the rest of English language.
Something thats circular(ish) or goes around in a circle. Its close enough.
Post by Michael S
Post by M***@DastartdlyHQ.org
Frankly borrow-checking can mean whatever they want it to mean this
week, but in general its what I said above.
Neither 'borrow' nor 'borrow checker' are Rust keywords. They are
abstract (more or less) concepts used in Rust manuals. And it seems
logical that it would be easier to explain the later if we explain the
former first.
Presumably the borrow means something "borrowed" the pointer, and checker means
checking the pointer is still valid. Doesn't seem complicated to me.
Michael S
2024-10-10 13:54:14 UTC
Permalink
On Thu, 10 Oct 2024 13:11:24 -0000 (UTC)
Post by M***@DastartdlyHQ.org
On Thu, 10 Oct 2024 14:10:47 +0300
Post by Michael S
On Thu, 10 Oct 2024 10:50:05 -0000 (UTC)
Post by M***@DastartdlyHQ.org
On Thu, 10 Oct 2024 13:44:59 +0300
Post by Michael S
On Thu, 10 Oct 2024 10:20:07 -0000 (UTC)
Post by M***@DastartdlyHQ.org
I think its just their way of checking if something could have
been altered before use in a way that might crash the program or
introduce bugs.
Now you're talking about meaning of 'borrow checker'.
Before we go that far we have to dig up the meaning of 'borrow'.
Since when do programming language keywords always mean the exact
same as the english equivalent? Last time I looked "for" didn't
mean "loop" in english.
Well, I don't know how it feels for native English speakers, but for
me meaning of 'loop' in programming is not equivalent to its meaning
in the rest of English language.
Something thats circular(ish) or goes around in a circle. Its close enough.
Post by Michael S
Post by M***@DastartdlyHQ.org
Frankly borrow-checking can mean whatever they want it to mean this
week, but in general its what I said above.
Neither 'borrow' nor 'borrow checker' are Rust keywords. They are
abstract (more or less) concepts used in Rust manuals. And it seems
logical that it would be easier to explain the later if we explain
the former first.
Presumably the borrow means something "borrowed" the pointer, and
checker means checking the pointer is still valid. Doesn't seem
complicated to me.
May be, for people that are used to smart pointers in C++, for people
that move their private parts from unique_ptr to shared_ptr to weak_ptr
forth, back and sideways, may be for these people Rust ownership and
borrowing business is not complicated. For me it is.
Paavo Helde
2024-10-10 15:08:48 UTC
Permalink
Post by Michael S
On Thu, 10 Oct 2024 13:11:24 -0000 (UTC)
Post by M***@DastartdlyHQ.org
On Thu, 10 Oct 2024 14:10:47 +0300
Post by Michael S
On Thu, 10 Oct 2024 10:50:05 -0000 (UTC)
Post by M***@DastartdlyHQ.org
On Thu, 10 Oct 2024 13:44:59 +0300
Post by Michael S
On Thu, 10 Oct 2024 10:20:07 -0000 (UTC)
Post by M***@DastartdlyHQ.org
I think its just their way of checking if something could have
been altered before use in a way that might crash the program or
introduce bugs.
Now you're talking about meaning of 'borrow checker'.
Before we go that far we have to dig up the meaning of 'borrow'.
Since when do programming language keywords always mean the exact
same as the english equivalent? Last time I looked "for" didn't
mean "loop" in english.
Well, I don't know how it feels for native English speakers, but for
me meaning of 'loop' in programming is not equivalent to its meaning
in the rest of English language.
Something thats circular(ish) or goes around in a circle. Its close enough.
Post by Michael S
Post by M***@DastartdlyHQ.org
Frankly borrow-checking can mean whatever they want it to mean this
week, but in general its what I said above.
Neither 'borrow' nor 'borrow checker' are Rust keywords. They are
abstract (more or less) concepts used in Rust manuals. And it seems
logical that it would be easier to explain the later if we explain
the former first.
Presumably the borrow means something "borrowed" the pointer, and
checker means checking the pointer is still valid. Doesn't seem
complicated to me.
May be, for people that are used to smart pointers in C++, for people
that move their private parts from unique_ptr to shared_ptr to weak_ptr
forth, back and sideways, may be for these people Rust ownership and
borrowing business is not complicated. For me it is.
From what I have understood, Rust borrowing is more related to
std::move() and rvalue references in C++. But yes, one thing which can
be moved around this way is indeed std::unique_ptr.
wij
2024-10-10 15:37:36 UTC
Permalink
Post by Michael S
On Thu, 10 Oct 2024 13:11:24 -0000 (UTC)
Post by M***@DastartdlyHQ.org
On Thu, 10 Oct 2024 14:10:47 +0300
Post by Michael S
On Thu, 10 Oct 2024 10:50:05 -0000 (UTC)
 
Post by M***@DastartdlyHQ.org
On Thu, 10 Oct 2024 13:44:59 +0300
Post by Michael S
On Thu, 10 Oct 2024 10:20:07 -0000 (UTC)
Post by M***@DastartdlyHQ.org
I think its just their way of checking if something could have
been altered before use in a way that might crash the program or
introduce bugs.
    
Now you're talking about meaning of 'borrow checker'.
Before we go that far we have to dig up the meaning of 'borrow'.
 
Since when do programming language keywords always mean the exact
same as the english equivalent? Last time I looked "for" didn't
mean "loop" in english.
  
Well, I don't know how it feels for native English speakers, but for
me meaning of 'loop' in programming is not equivalent to its meaning
in the rest of English language.
Something thats circular(ish) or goes around in a circle. Its close enough.
Post by Michael S
Post by M***@DastartdlyHQ.org
Frankly borrow-checking can mean whatever they want it to mean this
week, but in general its what I said above.
  
Neither 'borrow' nor 'borrow checker' are Rust keywords. They are
abstract (more or less) concepts used in Rust manuals. And it seems
logical that it would be easier to explain the later if we explain
the former first.
Presumably the borrow means something "borrowed" the pointer, and
checker means checking the pointer is still valid. Doesn't seem
complicated to me.
May be, for people that are used to smart pointers in C++, for people
that move their private parts from unique_ptr to shared_ptr to weak_ptr
forth, back and sideways, may be for these people Rust ownership and
borrowing business is not complicated. For me it is.
 From what I have understood, Rust borrowing is more related to
std::move() and rvalue references in C++. But yes, one thing which can
be moved around this way is indeed std::unique_ptr.
Lots of 'high level concept' invention are around the assembly "mov A,B"
What's for?
C++ is now basically a macro language for various programming concepts,
and *standardized* while announced as multi-lingual (fake).
Paavo Helde
2024-10-10 16:03:17 UTC
Permalink
Post by wij
Lots of 'high level concept' invention are around the assembly "mov A,B"
What's for?
Assembler "mov" is a misnamed "copy". So, no relation.
Michael S
2024-10-10 16:11:27 UTC
Permalink
On Thu, 10 Oct 2024 18:08:48 +0300
Post by Paavo Helde
Post by Michael S
On Thu, 10 Oct 2024 13:11:24 -0000 (UTC)
Post by M***@DastartdlyHQ.org
On Thu, 10 Oct 2024 14:10:47 +0300
Post by Michael S
On Thu, 10 Oct 2024 10:50:05 -0000 (UTC)
Post by M***@DastartdlyHQ.org
On Thu, 10 Oct 2024 13:44:59 +0300
Post by Michael S
On Thu, 10 Oct 2024 10:20:07 -0000 (UTC)
Post by M***@DastartdlyHQ.org
I think its just their way of checking if something could have
been altered before use in a way that might crash the program
or introduce bugs.
Now you're talking about meaning of 'borrow checker'.
Before we go that far we have to dig up the meaning of 'borrow'.
Since when do programming language keywords always mean the exact
same as the english equivalent? Last time I looked "for" didn't
mean "loop" in english.
Well, I don't know how it feels for native English speakers, but
for me meaning of 'loop' in programming is not equivalent to its
meaning in the rest of English language.
Something thats circular(ish) or goes around in a circle. Its close enough.
Post by Michael S
Post by M***@DastartdlyHQ.org
Frankly borrow-checking can mean whatever they want it to mean
this week, but in general its what I said above.
Neither 'borrow' nor 'borrow checker' are Rust keywords. They are
abstract (more or less) concepts used in Rust manuals. And it
seems logical that it would be easier to explain the later if we
explain the former first.
Presumably the borrow means something "borrowed" the pointer, and
checker means checking the pointer is still valid. Doesn't seem
complicated to me.
May be, for people that are used to smart pointers in C++, for
people that move their private parts from unique_ptr to shared_ptr
to weak_ptr forth, back and sideways, may be for these people Rust
ownership and borrowing business is not complicated. For me it is.
From what I have understood, Rust borrowing is more related to
std::move() and rvalue references in C++. But yes, one thing which
can be moved around this way is indeed std::unique_ptr.
My understanding is an opposite.
Borrowing is the case when the ownership is *not* moved by creation of
the reference. Something akin to shared_ptr in C++ and to
reference-counted object in Swift or may be even in Python. With the
major difference that in Rust references are counted by static analyzer
in compile time rather than by language runtime system (Swift) or by
the library (C++) in run time.

But then, not counting examples from tutorial, I wrote only one
full program in Rust and this program was rather simple. So it is
possible that I misunderstood.
David Brown
2024-10-10 18:01:47 UTC
Permalink
Post by Michael S
On Thu, 10 Oct 2024 18:08:48 +0300
Post by Paavo Helde
Post by Michael S
On Thu, 10 Oct 2024 13:11:24 -0000 (UTC)
Post by M***@DastartdlyHQ.org
On Thu, 10 Oct 2024 14:10:47 +0300
Post by Michael S
On Thu, 10 Oct 2024 10:50:05 -0000 (UTC)
Post by M***@DastartdlyHQ.org
On Thu, 10 Oct 2024 13:44:59 +0300
Post by Michael S
On Thu, 10 Oct 2024 10:20:07 -0000 (UTC)
Post by M***@DastartdlyHQ.org
I think its just their way of checking if something could have
been altered before use in a way that might crash the program
or introduce bugs.
Now you're talking about meaning of 'borrow checker'.
Before we go that far we have to dig up the meaning of 'borrow'.
Since when do programming language keywords always mean the exact
same as the english equivalent? Last time I looked "for" didn't
mean "loop" in english.
Well, I don't know how it feels for native English speakers, but
for me meaning of 'loop' in programming is not equivalent to its
meaning in the rest of English language.
Something thats circular(ish) or goes around in a circle. Its close enough.
Post by Michael S
Post by M***@DastartdlyHQ.org
Frankly borrow-checking can mean whatever they want it to mean
this week, but in general its what I said above.
Neither 'borrow' nor 'borrow checker' are Rust keywords. They are
abstract (more or less) concepts used in Rust manuals. And it
seems logical that it would be easier to explain the later if we
explain the former first.
Presumably the borrow means something "borrowed" the pointer, and
checker means checking the pointer is still valid. Doesn't seem
complicated to me.
May be, for people that are used to smart pointers in C++, for
people that move their private parts from unique_ptr to shared_ptr
to weak_ptr forth, back and sideways, may be for these people Rust
ownership and borrowing business is not complicated. For me it is.
From what I have understood, Rust borrowing is more related to
std::move() and rvalue references in C++. But yes, one thing which
can be moved around this way is indeed std::unique_ptr.
My understanding is an opposite.
Borrowing is the case when the ownership is *not* moved by creation of
the reference. Something akin to shared_ptr in C++ and to
reference-counted object in Swift or may be even in Python. With the
major difference that in Rust references are counted by static analyzer
in compile time rather than by language runtime system (Swift) or by
the library (C++) in run time.
But then, not counting examples from tutorial, I wrote only one
full program in Rust and this program was rather simple. So it is
possible that I misunderstood.
Without having used Rust myself, I think you are closer to the right
concept.

But I wonder if it is better to think of it as a kind of "locking".
Basically, if you have an object, then take a reference to the object or
a sub-object (such as an item in a container), then that "locks" the
object and makes it immutable until the reference is dead or out of scope.

Borrowing in Rust is only partially checked at unit compile time.
AFAIUI you also need to use a "borrow checker" after compilation to make
sure that cross-module borrows are safe.


(The concept of this kind of larger scale correctness analysis is not
actually new. If you have ever looked at the XMOS microcontrollers,
they are often programmed in a language called "XC" that amongst other
things has analysis to limit the access to data by different threads so
that you know there are no race conditions.)
Tim Rentsch
2024-10-10 14:56:39 UTC
Permalink
Post by Michael S
[suggested explanation of borrow checking]
Do you think that your explanation is sufficient for Lynn McGuire?
Consider that he probably doesn't know what Rust people have in mind
when they talk about ownership. And you can be sure that he doesn't
know the rusty meaning of 'borrow'.
Even I am not 100% sure that I understand the later, although it
seem to me that in their dialect 'borrow' means 'make a reference'.
Just a minor note here.. the word latter is spelled with two t's.

(fwiw I too have been frustrated by the inadequacy of descriptions
of Rust's features and concepts.)
Michael S
2024-10-10 15:56:00 UTC
Permalink
On Thu, 10 Oct 2024 07:56:39 -0700
Post by Tim Rentsch
Post by Michael S
[suggested explanation of borrow checking]
Do you think that your explanation is sufficient for Lynn McGuire?
Consider that he probably doesn't know what Rust people have in mind
when they talk about ownership. And you can be sure that he doesn't
know the rusty meaning of 'borrow'.
Even I am not 100% sure that I understand the later, although it
seem to me that in their dialect 'borrow' means 'make a reference'.
Just a minor note here.. the word latter is spelled with two t's.
Thank you. I would try to remember.
Ross Finlayson
2024-10-20 17:13:28 UTC
Permalink
Post by Lynn McGuire
Post by Lynn McGuire
"Safe C++ is A new Proposal to Make C++ Memory-Safe"
https://www.infoq.com/news/2024/10/safe-cpp-proposal/
"The goal of the Safe C++ proposal is extending C++ by defining a
superset of the language that can be used to write code with the
strong safety guarantees similarly to code written in Rust. The key to
its approach is introducing a new safe context where only a rigorously
safe subset of C++ is allowed."
"The Safe C++ proposal, set forth by Sean Baxter and Christian
Mazakas, originates from the growing awareness that C++ memory
unsafety lies at the root of a large part of vulnerabilities and
memory exploits. The only existing safe language, say Baxter and
Mazakas, is Rust, but their design differences limit interoperability,
thus making it hard to migrate from one language to the other. For
example, Rust lacks function overloading, templates, inheritance, and
exceptions, while C++ lacks traits, relocation, and borrow checking."
Lynn
And what the heck is relocation, traits, and borrow checking ?
Lynn
C++ has traits in templates, and move semantics, and
roll-your-own smart-pointers, ..., Rust is missing
exceptions and the corresponding defined behavior
according to initializer and constructor semantics,
and I'm not sure what it's got going on with static_cast,
which going outside the type system is of course entirely
prone error, vis-a-vis the theory of types.

A "safer" language would have less easy-to-write code
that entirely ignores ownership semantics of allocations.

I.e., that is to say, no "garbage collected" language
is quite "safe" in that sense.


You know they say "goto is dangerous or harmful" yet
at the same time it sort is the model of the instruction pointer,
and in effect _is_ implicit in every instruction?


Anyways managing allocations first-class would be safer
if you know how it is more error-prone because most
linear coders have lost the discipline and treat
everything like an owned singleton. Now, that's not
fair because there are all sorts who well manage all
sorts of allocator techniques that are correct, as
with regards to languages being "safe" and what that
means is being "correct", not being "stupid" and
"slightly less unlikely to make a double-free,
or orphan an allocated pointer, or especially,
to case data among types or make raw pointer
re-seating".


So, making allocation and ownership first-class in
the language, then making barriers of those first-class
in the language, then having type semantics strongly
in the language, and stack semantics for what exceptions
provide, that would be kind of safe and you can imagine
one of those as a subset of C++ (i.e., omitting static_cast)
then a library what hides accessors and discipline on objects,
about allocator patterns and pointer patterns and good-old
reference-counting.
jseigh
2024-10-10 16:13:50 UTC
Permalink
Post by Lynn McGuire
"Safe C++ is A new Proposal to Make C++ Memory-Safe"
   https://www.infoq.com/news/2024/10/safe-cpp-proposal/
"The goal of the Safe C++ proposal is extending C++ by defining a
superset of the language that can be used to write code with the strong
safety guarantees similarly to code written in Rust. The key to its
approach is introducing a new safe context where only a rigorously safe
subset of C++ is allowed."
"The Safe C++ proposal, set forth by Sean Baxter and Christian Mazakas,
originates from the growing awareness that C++ memory unsafety lies at
the root of a large part of vulnerabilities and memory exploits. The
only existing safe language, say Baxter and Mazakas, is Rust, but their
design differences limit interoperability, thus making it hard to
migrate from one language to the other. For example, Rust lacks function
overloading, templates, inheritance, and exceptions, while C++ lacks
traits, relocation, and borrow checking."
Lynn
For some definition of safe.

A lot of the problem is logically most stuff is treat as if
it was all move or copy by value. That's not feasible for
large data structures or where storage requirements aren't
known at compile time. So references get used and that's
problemantic since 2 references can share all or some of
their memory. So it looks like Rust does a lot of work
on detecting or managing aliasing.

Also there's ownership, responsibility to run the dtor,
deallocate heap storage, etc... RAII take care of a lot
of that but problems can occur when concurrency enters
the picture. Language architects and standards committees
don't have a very good understanding of concurrency and
tend to architect some really sub-optimal stuff from a
concurrent programming point of view. Just look at
rustaceans trying to explain how ARC ownership works.
There's no formal ownership mechanism there, it just
gets swept under the Rust rug of unsafe.

Rust unsafe is how they punt on the issue. Basically
you use unsafe to code stuff Rust doesn't have the
mechanisms for but the authors of said code have to
guarantee their code meets Rust safety at the api
level. Do you feel lucky?

Also it's very telling that restaceans claim that
Rust is super fast and yet promote reference counting
as the way to share objects when reference counting
is one of the least performant ways of doing that.


Traits are nice. Nothing to do with safety AFAIK. They are sort
of like Java interfaces or C++ abstract methods except they can
be defined outside of the class definition. I would have
really liked something like that in Java. Shouldn't be too
hard to add to C++, though it would be nice that if the type
was known at compile time they avoid the virtual method
vtables and inline where possible and feasible.

Joe Seigh
Bonita Montero
2024-10-10 16:29:18 UTC
Permalink
Post by Lynn McGuire
"Safe C++ is A new Proposal to Make C++ Memory-Safe"
   https://www.infoq.com/news/2024/10/safe-cpp-proposal/
"The goal of the Safe C++ proposal is extending C++ by defining a
superset of the language that can be used to write code with the strong
safety guarantees similarly to code written in Rust. The key to its
approach is introducing a new safe context where only a rigorously safe
subset of C++ is allowed."
"The Safe C++ proposal, set forth by Sean Baxter and Christian Mazakas,
originates from the growing awareness that C++ memory unsafety lies at
the root of a large part of vulnerabilities and memory exploits. The
only existing safe language, say Baxter and Mazakas, is Rust, but their
design differences limit interoperability, thus making it hard to
migrate from one language to the other. For example, Rust lacks function
overloading, templates, inheritance, and exceptions, while C++ lacks
traits, relocation, and borrow checking."
Lynn
I try to make C++ as safe as possible by using iterator debugging.
All pointers on flat memory with attached immediately into a span
iterator to care for bounds like with the where-iterator in the
following code.

str.resize_and_overwrite( (views.length() + ...), [&](
String::value_type *p, size_t n )
{
auto where = span( p, n ).begin();
((where = copy( views.begin(), views.end(), where )), ...);
return n;
} );
Vir Campestris
2024-10-20 11:37:45 UTC
Permalink
Post by Lynn McGuire
"Safe C++ is A new Proposal to Make C++ Memory-Safe"
   https://www.infoq.com/news/2024/10/safe-cpp-proposal/
"The goal of the Safe C++ proposal is extending C++ by defining a
superset of the language that can be used to write code with the strong
safety guarantees similarly to code written in Rust. The key to its
approach is introducing a new safe context where only a rigorously safe
subset of C++ is allowed."
"The Safe C++ proposal, set forth by Sean Baxter and Christian Mazakas,
originates from the growing awareness that C++ memory unsafety lies at
the root of a large part of vulnerabilities and memory exploits. The
only existing safe language, say Baxter and Mazakas, is Rust, but their
design differences limit interoperability, thus making it hard to
migrate from one language to the other. For example, Rust lacks function
overloading, templates, inheritance, and exceptions, while C++ lacks
traits, relocation, and borrow checking."
Lynn
a superset of the language
This means it has everything that C++ has, and some more stuff as well.
I'm pretty sure they mean a subset.

Andy
Michael S
2024-10-20 11:46:55 UTC
Permalink
On Sun, 20 Oct 2024 12:37:45 +0100
Post by Vir Campestris
Post by Lynn McGuire
"Safe C++ is A new Proposal to Make C++ Memory-Safe"
   https://www.infoq.com/news/2024/10/safe-cpp-proposal/
"The goal of the Safe C++ proposal is extending C++ by defining a
superset of the language that can be used to write code with the
strong safety guarantees similarly to code written in Rust. The key
to its approach is introducing a new safe context where only a
rigorously safe subset of C++ is allowed."
"The Safe C++ proposal, set forth by Sean Baxter and Christian
Mazakas, originates from the growing awareness that C++ memory
unsafety lies at the root of a large part of vulnerabilities and
memory exploits. The only existing safe language, say Baxter and
Mazakas, is Rust, but their design differences limit
interoperability, thus making it hard to migrate from one language
to the other. For example, Rust lacks function overloading,
templates, inheritance, and exceptions, while C++ lacks traits,
relocation, and borrow checking."
Lynn
a superset of the language
This means it has everything that C++ has, and some more stuff as
well. I'm pretty sure they mean a subset.
Andy
Ignore clueless Sergio De Simone. His article couses nothing but
misunderstanding.
Go straight to the proposal.
https://safecpp.org/P3390R0.html#relocation-object-model

"The goal of this proposal is to advance a superset of C++ with a
rigorously safe subset."
M***@DastartdlyHQ.org
2024-10-20 14:23:01 UTC
Permalink
On Sun, 20 Oct 2024 14:46:55 +0300
Post by Michael S
On Sun, 20 Oct 2024 12:37:45 +0100
Post by Vir Campestris
Post by Lynn McGuire
"Safe C++ is A new Proposal to Make C++ Memory-Safe"
=A0=A0 https://www.infoq.com/news/2024/10/safe-cpp-proposal/
=20
"The goal of the Safe C++ proposal is extending C++ by defining a=20
superset of the language that can be used to write code with the
strong safety guarantees similarly to code written in Rust. The key
to its approach is introducing a new safe context where only a
rigorously safe subset of C++ is allowed."
=20
"The Safe C++ proposal, set forth by Sean Baxter and Christian
Mazakas, originates from the growing awareness that C++ memory
unsafety lies at the root of a large part of vulnerabilities and
memory exploits. The only existing safe language, say Baxter and
Mazakas, is Rust, but their design differences limit
interoperability, thus making it hard to migrate from one language
to the other. For example, Rust lacks function overloading,
templates, inheritance, and exceptions, while C++ lacks traits,
relocation, and borrow checking."
=20
Lynn
=20
=20
Post by Lynn McGuire
a superset of the language =20
=20
This means it has everything that C++ has, and some more stuff as
well. I'm pretty sure they mean a subset.
=20
Andy
Ignore clueless Sergio De Simone. His article couses nothing but
misunderstanding.
Go straight to the proposal.
https://safecpp.org/P3390R0.html#relocation-object-model
"The goal of this proposal is to advance a superset of C++ with a
rigorously safe subset."
Why bother. All thats needed is a new keyword, perhaps "safe".

Trivial example:

safe
{
int i[10];
int j = 10;
cout << i[j];
};

This would fail to compile or if the check couldn't be done at compile time
any invalid memory accesses within the "safe" block could runtime abort with a
useful error instead of just ploughing ahead and crashing or corrupting the
code later anyway with the expense of runtime checking costs.

Possibly even a handler function could be set for this eventuality (no,
catching a SIGSEGV/BUS isn't the same as you don't know whats been corrupted
so can't do anything useful in the sig handler anyway).
jseigh
2024-10-27 23:09:16 UTC
Permalink
Post by Lynn McGuire
"Safe C++ is A new Proposal to Make C++ Memory-Safe"
   https://www.infoq.com/news/2024/10/safe-cpp-proposal/
"The goal of the Safe C++ proposal is extending C++ by defining a
superset of the language that can be used to write code with the strong
safety guarantees similarly to code written in Rust. The key to its
approach is introducing a new safe context where only a rigorously safe
subset of C++ is allowed."
"The Safe C++ proposal, set forth by Sean Baxter and Christian Mazakas,
originates from the growing awareness that C++ memory unsafety lies at
the root of a large part of vulnerabilities and memory exploits. The
only existing safe language, say Baxter and Mazakas, is Rust, but their
design differences limit interoperability, thus making it hard to
migrate from one language to the other. For example, Rust lacks function
overloading, templates, inheritance, and exceptions, while C++ lacks
traits, relocation, and borrow checking."
Lynn
Dealing with nullable pointers. Apparently some get really
freaked out by NPEs. Could be worse. I worked on platforms
where address 0 was readable without causing a segfault or
protection exception right away. You'd get a core dump but
with no indication of what code loaded the null ptr without
checking or why. Fortunately, on this platform you could
run an instruction trace to the terminal and wait for it
to stop. You'd then just go backward thru the trace until
the ip matched actual code. Anyway ...

You create a new nullable attribute for pointers. That
would make the pointer behave like void* instead of T*.
You could move, copy, and compare, but you could not
dereference them. If you wanted to dereference them
you would have to apply a special not_null unary predicate
to them. What makes it special is the boolean result
is only valid inside a conditional expression. It's
not copyable or referencable. You could have 1 or
more of these in a conditional expression along with
ordinary predicates with the restriction that the
expression has to be formed such that if any of the
not_null terms are false, the expression has to
evaluate as false.

The other thing that makes not_null is that inside
if the conditional statements true blocks, the
nullable pointer gets it T* properties back, so
you can dereference it, but again only in the
true blocks. So for example

nullable T* p = &something;

T p2 = *p; // invalid, compiler thinks you are trying
// do dereference void*

not_null(p); // invalid, not inside conditional expression

if (not_null(p)
p2 = *p; // valid
else
p2 = *p; // invalid


Traversing a linked list would look like

T* p = head;
while (not_null(p)) {
...
p = p->next; // valid, inside while true block
}

not_null would look like
__predicate_bool not_null(T *&)
It would make a const copy of T*, test that,
cast to T*, use it for the true block.

So no NPEs possible for pointer with this
attribute.

AFAICT, you can't do this with templates.

Joe Seigh
jseigh
2024-10-28 00:40:29 UTC
Permalink
Post by jseigh
Traversing a linked list would look like
T* p = head;
while (not_null(p)) {
  ...
  p = p->next;    // valid, inside while true block
}
I should add, the p->next is also nullable so the
assignment to p makes it nullable again. The
goal is to make the code look like normal code
while ensuring null pointer safety.
wij
2024-10-28 01:22:38 UTC
Permalink
Post by jseigh
Post by jseigh
Traversing a linked list would look like
T* p = head;
while (not_null(p)) {
   ...
   p = p->next;    // valid, inside while true block
}
I should add, the p->next is also nullable so the
assignment to p makes it nullable again.  The
goal is to make the code look like normal code
while ensuring null pointer safety.
C++ is an object oriented language. 
In C++, programming in C concept makes little sense.
Chris M. Thomasson
2024-10-28 04:18:57 UTC
Permalink
Post by wij
Post by jseigh
Post by jseigh
Traversing a linked list would look like
T* p = head;
while (not_null(p)) {
   ...
   p = p->next;    // valid, inside while true block
}
I should add, the p->next is also nullable so the
assignment to p makes it nullable again.  The
goal is to make the code look like normal code
while ensuring null pointer safety.
C++ is an object oriented language.
In C++, programming in C concept makes little sense.
Well, sometimes for some exotic algorithms we can steal a bit and say
this is a null (the bit is set) even though its not equal to nullptr.
It's null but it still points to a node. This can be called a so-called
dummy node, sometimes. The logic with dummy nodes can be beneficial.
jseigh
2024-10-28 16:25:39 UTC
Permalink
Post by Chris M. Thomasson
Post by wij
Post by jseigh
Post by jseigh
Traversing a linked list would look like
T* p = head;
while (not_null(p)) {
    ...
    p = p->next;    // valid, inside while true block
}
I should add, the p->next is also nullable so the
assignment to p makes it nullable again.  The
goal is to make the code look like normal code
while ensuring null pointer safety.
C++ is an object oriented language.
In C++, programming in C concept makes little sense.
Well, sometimes for some exotic algorithms we can steal a bit and say
this is a null (the bit is set) even though its not equal to nullptr.
It's null but it still points to a node. This can be called a so-called
dummy node, sometimes. The logic with dummy nodes can be beneficial.
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.

The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.

At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.

Joe Seigh
jseigh
2024-10-30 16:56:38 UTC
Permalink
On 10/28/24 12:25, jseigh wrote:
...
Post by jseigh
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance. I don't think will
solve all the issues they think it will. I can come up
with some pretty trivial examples that will break their
proposed solutions. I think they are unicorn hunting here.

One of the issues they brought up is the ABA problem. Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues. Kind of hard
to take the pointer provenance problem seriously.

Joe Seigh
Chris M. Thomasson
2024-10-30 19:50:55 UTC
Permalink
Post by jseigh
...
Post by jseigh
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance.  I don't think will
solve all the issues they think it will.  I can come up
with some pretty trivial examples that will break their
proposed solutions.  I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem.  Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues.  Kind of hard
to take the pointer provenance problem seriously.
Are you referring to DWCAS? There has to be a compiler out there that
can handle it wrt it being, always lock-free ala:
__________________
​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.
__________________

Damn it! ;^/
jseigh
2024-10-30 20:31:25 UTC
Permalink
Post by Chris M. Thomasson
Post by jseigh
...
Post by jseigh
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance.  I don't think will
solve all the issues they think it will.  I can come up
with some pretty trivial examples that will break their
proposed solutions.  I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem.  Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues.  Kind of hard
to take the pointer provenance problem seriously.
Are you referring to DWCAS? There has to be a compiler out there that
__________________
​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.
__________________
Damn it! ;^/
No. AFAIK everyone uses assembler. gcc has a builtin that
calls a library function which uses locks because soemwhere
in a museum there is an x86 computer that doesn't have
cmpxchg16b and in theory it someone port new versions of
linux and gcc to it, it wouldn't work. It sound stupid
because it is stupid.
Chris M. Thomasson
2024-11-04 20:47:04 UTC
Permalink
Post by jseigh
Post by Chris M. Thomasson
Post by jseigh
...
Post by jseigh
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance.  I don't think will
solve all the issues they think it will.  I can come up
with some pretty trivial examples that will break their
proposed solutions.  I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem.  Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues.  Kind of hard
to take the pointer provenance problem seriously.
Are you referring to DWCAS? There has to be a compiler out there that
__________________
​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.
__________________
Damn it! ;^/
No. AFAIK everyone uses assembler.
Ahh shit. This brings back memories of coding things up in asm... The
wayback machine has some of my old code on it:

https://web.archive.org/web/20060214112345/http://appcore.home.comcast.net/appcore/src/cpu/i686/ac_i686_gcc_asm.html

;^o
Post by jseigh
gcc has a builtin that
calls a library function which uses locks because soemwhere
in a museum there is an x86 computer that doesn't have
cmpxchg16b and in theory it someone port new versions of
linux and gcc to it, it wouldn't work.  It sound stupid
because it is stupid.
jseigh
2024-11-07 12:02:13 UTC
Permalink
Post by jseigh
...
Post by jseigh
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance.  I don't think will
solve all the issues they think it will.  I can come up
with some pretty trivial examples that will break their
proposed solutions.  I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem.  Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues.  Kind of hard
to take the pointer provenance problem seriously.
I did come up with an interesting solution. It should work
on top of the proxy stuff but is not integral to it. But
I need to finish porting the proxy stuff to c++.
Lynn McGuire
2024-11-08 02:14:15 UTC
Permalink
Post by jseigh
...
Post by jseigh
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance.  I don't think will
solve all the issues they think it will.  I can come up
with some pretty trivial examples that will break their
proposed solutions.  I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem.  Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues.  Kind of hard
to take the pointer provenance problem seriously.
Joe Seigh
What is the ABA problem ?

Lynn
jseigh
2024-11-08 14:40:58 UTC
Permalink
Post by Lynn McGuire
Post by jseigh
...
Post by jseigh
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance.  I don't think will
solve all the issues they think it will.  I can come up
with some pretty trivial examples that will break their
proposed solutions.  I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem.  Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues.  Kind of hard
to take the pointer provenance problem seriously.
Joe Seigh
What is the ABA problem ?
Things like using single word compare and swap to pop something
off a stack where the stack was modified between the initial
load of the stack head and the top of stack is same but
the item after it is different.

Stack at initial load
x -> a -> b ...

Stack before cas of x from a to b for pop operation
because it changed.
x -> a -> c ...

Stack after pop
x -> b (b having possibly unknown memory state)

System370 has cds (double wide cas) to avoid the ABA problem
in the 70's.

Supporting DWCAS in C/C++ is NOT a technical problem.

Joe Seigh
Scott Lurndal
2024-11-08 14:48:16 UTC
Permalink
Post by Lynn McGuire
Post by jseigh
...
Post by jseigh
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance.  I don't think will
solve all the issues they think it will.  I can come up
with some pretty trivial examples that will break their
proposed solutions.  I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem.  Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues.  Kind of hard
to take the pointer provenance problem seriously.
Joe Seigh
What is the ABA problem ?
Lynn
https://en.wikipedia.org/wiki/ABA_problem
M***@DastartdlyHQ.org
2024-11-08 14:54:08 UTC
Permalink
On Fri, 08 Nov 2024 14:48:16 GMT
Post by Scott Lurndal
Post by Lynn McGuire
Post by jseigh
...
Post by jseigh
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance.  I don't think will
solve all the issues they think it will.  I can come up
with some pretty trivial examples that will break their
proposed solutions.  I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem.  Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues.  Kind of hard
to take the pointer provenance problem seriously.
Joe Seigh
What is the ABA problem ?
Lynn
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist. Why would anyone expect non
synchronised RW memory access to work? The exact same problem occurs
in databases with dirty reads.
Chris M. Thomasson
2024-11-08 20:40:36 UTC
Permalink
Post by M***@DastartdlyHQ.org
On Fri, 08 Nov 2024 14:48:16 GMT
Post by Scott Lurndal
Post by Lynn McGuire
Post by jseigh
...
Post by jseigh
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance.  I don't think will
solve all the issues they think it will.  I can come up
with some pretty trivial examples that will break their
proposed solutions.  I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem.  Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues.  Kind of hard
to take the pointer provenance problem seriously.
Joe Seigh
What is the ABA problem ?
Lynn
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist.
What if one did not want to use a mutex?
Post by M***@DastartdlyHQ.org
Why would anyone expect non
synchronised RW memory access to work? The exact same problem occurs
in databases with dirty reads.
M***@dastardlyhq.com
2024-11-09 12:01:10 UTC
Permalink
On Fri, 8 Nov 2024 12:40:36 -0800
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
Post by Scott Lurndal
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist.
What if one did not want to use a mutex?
Then put up with the faff of semaphores or atomics and risk creating some
edge case race conditions. If you're worried about threads getting blocked
too often then you haven't designed your program correctly.
Chris M. Thomasson
2024-11-09 20:39:19 UTC
Permalink
Post by M***@dastardlyhq.com
On Fri, 8 Nov 2024 12:40:36 -0800
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
Post by Scott Lurndal
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist.
What if one did not want to use a mutex?
Then put up with the faff of semaphores or atomics and risk creating some
edge case race conditions.
Using lock/wait/obstruction-free algorithms is not about creating race
conditions... :^)
Post by M***@dastardlyhq.com
If you're worried about threads getting blocked
too often then you haven't designed your program correctly.
Not sure what you mean here... It's all about minimizing slow-paths, and
maximizing fast-paths. :^)
M***@DastartdlyHQ.org
2024-11-11 09:56:06 UTC
Permalink
On Sat, 9 Nov 2024 12:39:19 -0800
Post by Chris M. Thomasson
Post by M***@dastardlyhq.com
On Fri, 8 Nov 2024 12:40:36 -0800
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
Post by Scott Lurndal
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist.
What if one did not want to use a mutex?
Then put up with the faff of semaphores or atomics and risk creating some
edge case race conditions.
Using lock/wait/obstruction-free algorithms is not about creating race
conditions... :^)
3 level locking generally solves most problems IME. C++ didn't have until 2017
when shared_mutex came along even though pthreads has had it forever and was
a reason people kept using pthreads in C++.
Post by Chris M. Thomasson
Not sure what you mean here... It's all about minimizing slow-paths, and
maximizing fast-paths. :^)
Fast paths are no use if the thread doesn't have anything else to do anyway.
Chris M. Thomasson
2024-11-11 21:36:53 UTC
Permalink
Post by M***@DastartdlyHQ.org
On Sat, 9 Nov 2024 12:39:19 -0800
Post by Chris M. Thomasson
Post by M***@dastardlyhq.com
On Fri, 8 Nov 2024 12:40:36 -0800
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
Post by Scott Lurndal
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist.
What if one did not want to use a mutex?
Then put up with the faff of semaphores or atomics and risk creating some
edge case race conditions.
Using lock/wait/obstruction-free algorithms is not about creating race
conditions... :^)
3 level locking generally solves most problems IME. C++ didn't have until 2017
when shared_mutex came along even though pthreads has had it forever and was
a reason people kept using pthreads in C++.
Not sure what you mean by 3 level locking. Are you talking about
PTHREAD_MUTEX_RECURSIVE? ohhh. I have had to debug some very nasty
conditions that used recursive locks. Ouch.
Post by M***@DastartdlyHQ.org
Post by Chris M. Thomasson
Not sure what you mean here... It's all about minimizing slow-paths, and
maximizing fast-paths. :^)
Fast paths are no use if the thread doesn't have anything else to do anyway.
If a thread has nothing to do, it can wait, for something to do. ;^)

Think of an empty queue condition. A thread can just wait on it...
M***@DastartdlyHQ.org
2024-11-12 08:28:27 UTC
Permalink
On Mon, 11 Nov 2024 13:36:53 -0800
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
On Sat, 9 Nov 2024 12:39:19 -0800
Post by Chris M. Thomasson
Post by M***@dastardlyhq.com
On Fri, 8 Nov 2024 12:40:36 -0800
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
Post by Scott Lurndal
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist.
What if one did not want to use a mutex?
Then put up with the faff of semaphores or atomics and risk creating some
edge case race conditions.
Using lock/wait/obstruction-free algorithms is not about creating race
conditions... :^)
3 level locking generally solves most problems IME. C++ didn't have until
2017
Post by M***@DastartdlyHQ.org
when shared_mutex came along even though pthreads has had it forever and was
a reason people kept using pthreads in C++.
Not sure what you mean by 3 level locking. Are you talking about
Seriously?
Post by Chris M. Thomasson
PTHREAD_MUTEX_RECURSIVE? ohhh. I have had to debug some very nasty
conditions that used recursive locks. Ouch.
No, I'm talking about read locks vs read-write locks.
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
Fast paths are no use if the thread doesn't have anything else to do anyway.
If a thread has nothing to do, it can wait, for something to do. ;^)
Think of an empty queue condition. A thread can just wait on it...
Sure, but then who needs a "fast path"? Just sit on the mutex/condition
variable.
Chris M. Thomasson
2024-11-12 21:56:46 UTC
Permalink
Post by M***@DastartdlyHQ.org
On Mon, 11 Nov 2024 13:36:53 -0800
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
On Sat, 9 Nov 2024 12:39:19 -0800
Post by Chris M. Thomasson
Post by M***@dastardlyhq.com
On Fri, 8 Nov 2024 12:40:36 -0800
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
Post by Scott Lurndal
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist.
What if one did not want to use a mutex?
Then put up with the faff of semaphores or atomics and risk creating some
edge case race conditions.
Using lock/wait/obstruction-free algorithms is not about creating race
conditions... :^)
3 level locking generally solves most problems IME. C++ didn't have until
2017
Post by M***@DastartdlyHQ.org
when shared_mutex came along even though pthreads has had it forever and was
a reason people kept using pthreads in C++.
Not sure what you mean by 3 level locking. Are you talking about
Seriously?
Post by Chris M. Thomasson
PTHREAD_MUTEX_RECURSIVE? ohhh. I have had to debug some very nasty
conditions that used recursive locks. Ouch.
No, I'm talking about read locks vs read-write locks.
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
Fast paths are no use if the thread doesn't have anything else to do anyway.
If a thread has nothing to do, it can wait, for something to do. ;^)
Think of an empty queue condition. A thread can just wait on it...
Sure, but then who needs a "fast path"? Just sit on the mutex/condition
variable.
lock/wait free fast-paths really shine when the system is under _load_.
They allow for damn good scalability. A mutex has a lot of trouble
scaling. Even distributed mutexes cannot scale as good.
Chris M. Thomasson
2024-11-12 21:59:19 UTC
Permalink
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
On Mon, 11 Nov 2024 13:36:53 -0800
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
On Sat, 9 Nov 2024 12:39:19 -0800
Post by Chris M. Thomasson
Post by M***@dastardlyhq.com
On Fri, 8 Nov 2024 12:40:36 -0800
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
Post by Scott Lurndal
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist.
What if one did not want to use a mutex?
Then put up with the faff of semaphores or atomics and risk creating some
edge case race conditions.
Using lock/wait/obstruction-free algorithms is not about creating race
conditions... :^)
3 level locking generally solves most problems IME. C++ didn't have until
2017
Post by M***@DastartdlyHQ.org
when shared_mutex came along even though pthreads has had it forever and was
a reason people kept using pthreads in C++.
Not sure what you mean by 3 level locking. Are you talking about
Seriously?
Post by Chris M. Thomasson
PTHREAD_MUTEX_RECURSIVE? ohhh. I have had to debug some very nasty
conditions that used recursive locks. Ouch.
No, I'm talking about read locks vs read-write locks.
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
Fast paths are no use if the thread doesn't have anything else to do anyway.
If a thread has nothing to do, it can wait, for something to do. ;^)
Think of an empty queue condition. A thread can just wait on it...
Sure, but then who needs a "fast path"? Just sit on the mutex/condition
variable.
lock/wait free fast-paths really shine when the system is under _load_.
They allow for damn good scalability. A mutex has a lot of trouble
scaling. Even distributed mutexes cannot scale as good.
Think of comparing a mutex based solution vs something like, RCU. The
performance is not even barely close.
Ross Finlayson
2024-11-13 00:20:42 UTC
Permalink
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
On Mon, 11 Nov 2024 13:36:53 -0800
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
On Sat, 9 Nov 2024 12:39:19 -0800
Post by Chris M. Thomasson
Post by M***@dastardlyhq.com
On Fri, 8 Nov 2024 12:40:36 -0800
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
Post by Scott Lurndal
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist.
What if one did not want to use a mutex?
Then put up with the faff of semaphores or atomics and risk creating some
edge case race conditions.
Using lock/wait/obstruction-free algorithms is not about creating race
conditions... :^)
3 level locking generally solves most problems IME. C++ didn't have until
2017
Post by M***@DastartdlyHQ.org
when shared_mutex came along even though pthreads has had it forever and was
a reason people kept using pthreads in C++.
Not sure what you mean by 3 level locking. Are you talking about
Seriously?
Post by Chris M. Thomasson
PTHREAD_MUTEX_RECURSIVE? ohhh. I have had to debug some very nasty
conditions that used recursive locks. Ouch.
No, I'm talking about read locks vs read-write locks.
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
Fast paths are no use if the thread doesn't have anything else to do anyway.
If a thread has nothing to do, it can wait, for something to do. ;^)
Think of an empty queue condition. A thread can just wait on it...
Sure, but then who needs a "fast path"? Just sit on the mutex/condition
variable.
lock/wait free fast-paths really shine when the system is under _load_.
They allow for damn good scalability. A mutex has a lot of trouble
scaling. Even distributed mutexes cannot scale as good.
Well, there's design for correctness, and Murphy's law,
and hope for the best, and Murphy's law.

A usual notion of "non-blocking co-operatively" makes for
a usual notion of "incremental progress".

Which is usually implemented as pre-emptive multi-threading, ....

Where round-robin is usually considered fair, ....


It's like an idea about a digital signal processor,
and the systolic and constant-rate, and the idea
that anything that backs up needs a buffer, on the chip,
vis-a-vis, keeping the DMA bus hot, versus keeping it not.


Guy was like "I overclocked a simple routine,
now all you need to do is add a huge burst-buffer",
and it's like, "well then you won't mind it coming
out of your budget".

Or like "just add a huge cache, don't worry
that anybody will mess with it".

The branch-free paths really shine under load, ....


There is contention for resources, ..., yet the
over-allocation is a usual failure mode of
the budgetary analysis.



"What's the best performing routine on that system?"

"I don't know, it just says 'idle'."
Ross Finlayson
2024-11-10 21:02:37 UTC
Permalink
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
On Fri, 08 Nov 2024 14:48:16 GMT
Post by Scott Lurndal
Post by Lynn McGuire
Post by jseigh
...
Post by jseigh
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance. I don't think will
solve all the issues they think it will. I can come up
with some pretty trivial examples that will break their
proposed solutions. I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem. Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues. Kind of hard
to take the pointer provenance problem seriously.
Joe Seigh
What is the ABA problem ?
Lynn
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist.
What if one did not want to use a mutex?
Post by M***@DastartdlyHQ.org
Why would anyone expect non
synchronised RW memory access to work? The exact same problem occurs
in databases with dirty reads.
Usually called serialization or "the monad", ....

The database as a critical transactional resource
via serialization is sort of exactly a sort of
memory barrier with regards to defined behavior
that reduced pretty much to compare-and-swap,
then incrementing a counter in that as a tuple.

I.e., when compare-and-swap is the only atomic operation.
Ross Finlayson
2024-11-10 21:05:24 UTC
Permalink
Post by Ross Finlayson
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
On Fri, 08 Nov 2024 14:48:16 GMT
Post by Scott Lurndal
Post by Lynn McGuire
Post by jseigh
...
Post by jseigh
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance. I don't think will
solve all the issues they think it will. I can come up
with some pretty trivial examples that will break their
proposed solutions. I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem. Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues. Kind of hard
to take the pointer provenance problem seriously.
Joe Seigh
What is the ABA problem ?
Lynn
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist.
What if one did not want to use a mutex?
Post by M***@DastartdlyHQ.org
Why would anyone expect non
synchronised RW memory access to work? The exact same problem occurs
in databases with dirty reads.
Usually called serialization or "the monad", ....
The database as a critical transactional resource
via serialization is sort of exactly a sort of
memory barrier with regards to defined behavior
that reduced pretty much to compare-and-swap,
then incrementing a counter in that as a tuple.
I.e., when compare-and-swap is the only atomic operation.
It's sort of up to the OS according to the architecture,
that critical resources are smaller.

Correctness of course is usually considered paramount,
with regards to something like buffers as queues,
and atomic swap on the tail, for a most usual sort
of algorithm the "slique" or "mono-hydra", with regards
to read-twice consume-once, what results then non-blocking,
and re-entrant.
Chris M. Thomasson
2024-11-08 20:46:54 UTC
Permalink
Post by M***@DastartdlyHQ.org
On Fri, 08 Nov 2024 14:48:16 GMT
Post by Scott Lurndal
Post by Lynn McGuire
Post by jseigh
...
Post by jseigh
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance.  I don't think will
solve all the issues they think it will.  I can come up
with some pretty trivial examples that will break their
proposed solutions.  I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem.  Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues.  Kind of hard
to take the pointer provenance problem seriously.
Joe Seigh
What is the ABA problem ?
Lynn
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist. Why would anyone expect non
synchronised RW memory access to work? The exact same problem occurs
in databases with dirty reads.
Humm... Not sure what to make of that comment. Have you ever
experimented with lock-free algorithms?
wij
2024-11-08 21:18:58 UTC
Permalink
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
On Fri, 08 Nov 2024 14:48:16 GMT
Post by Scott Lurndal
Post by Lynn McGuire
Post by jseigh
...
Post by jseigh
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance.  I don't think will
solve all the issues they think it will.  I can come up
with some pretty trivial examples that will break their
proposed solutions.  I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem.  Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues.  Kind of hard
to take the pointer provenance problem seriously.
Joe Seigh
What is the ABA problem ?
Lynn
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist. Why would anyone expect non
synchronised RW memory access to work? The exact same problem occurs
in databases with dirty reads.
Humm... Not sure what to make of that comment. Have you ever
experimented with lock-free algorithms?
Why is it on topic?

If "lock-free algorithms" is on topic, why just turn off multi-tasking?
Chris M. Thomasson
2024-11-08 21:23:43 UTC
Permalink
Post by wij
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
On Fri, 08 Nov 2024 14:48:16 GMT
Post by Scott Lurndal
Post by Lynn McGuire
Post by jseigh
...
Post by jseigh
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance.  I don't think will
solve all the issues they think it will.  I can come up
with some pretty trivial examples that will break their
proposed solutions.  I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem.  Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues.  Kind of hard
to take the pointer provenance problem seriously.
Joe Seigh
What is the ABA problem ?
Lynn
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist. Why would anyone expect non
synchronised RW memory access to work? The exact same problem occurs
in databases with dirty reads.
Humm... Not sure what to make of that comment. Have you ever
experimented with lock-free algorithms?
Why is it on topic?
If "lock-free algorithms" is on topic, why just turn off multi-tasking?
Well, C++11 allows us to create lock-free algorithms using pure standard
C++. The DWCAS issue aside for a moment. Well, it's on topic wrt C++
itself? Standard atomics and memory barriers... Compiler barriers to
boot via atomic_signal_fence:

https://en.cppreference.com/w/cpp/atomic/atomic_signal_fence

I still don't know why its so hard to apply lock-free DWCAS to the std.
Well, wrt always lock-free using C++'s own terms...

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

;^)

I love C++'s "sometimes" lock-free wording... Oh wow.
wij
2024-11-08 21:25:08 UTC
Permalink
Post by wij
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
On Fri, 08 Nov 2024 14:48:16 GMT
Post by Scott Lurndal
Post by Lynn McGuire
Post by jseigh
...
Post by jseigh
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance.  I don't think will
solve all the issues they think it will.  I can come up
with some pretty trivial examples that will break their
proposed solutions.  I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem.  Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues.  Kind of hard
to take the pointer provenance problem seriously.
Joe Seigh
What is the ABA problem ?
Lynn
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist. Why would anyone expect non
synchronised RW memory access to work? The exact same problem occurs
in databases with dirty reads.
Humm... Not sure what to make of that comment. Have you ever
experimented with lock-free algorithms?
Why is it on topic?
If "lock-free algorithms" is on topic, why just turn off multi-tasking?
Typo: why not just turning off multi-tasking?
Chris M. Thomasson
2024-11-08 21:27:27 UTC
Permalink
Post by wij
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
On Fri, 08 Nov 2024 14:48:16 GMT
Post by Scott Lurndal
Post by Lynn McGuire
Post by jseigh
...
Post by jseigh
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance.  I don't think will
solve all the issues they think it will.  I can come up
with some pretty trivial examples that will break their
proposed solutions.  I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem.  Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues.  Kind of hard
to take the pointer provenance problem seriously.
Joe Seigh
What is the ABA problem ?
Lynn
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist. Why would anyone expect non
synchronised RW memory access to work? The exact same problem occurs
in databases with dirty reads.
Humm... Not sure what to make of that comment. Have you ever
experimented with lock-free algorithms?
Why is it on topic?
If "lock-free algorithms" is on topic, why just turn off multi-tasking?
I am not exactly sure what you mean by your question wrt "why just turn
off multi-tasking"? Just use a single thread in your program?
wij
2024-11-08 22:02:57 UTC
Permalink
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
On Fri, 08 Nov 2024 14:48:16 GMT
Post by Scott Lurndal
Post by Lynn McGuire
Post by jseigh
...
Post by jseigh
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance.  I don't think will
solve all the issues they think it will.  I can come up
with some pretty trivial examples that will break their
proposed solutions.  I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem.  Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues.  Kind of hard
to take the pointer provenance problem seriously.
Joe Seigh
What is the ABA problem ?
Lynn
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist. Why would anyone expect non
synchronised RW memory access to work? The exact same problem occurs
in databases with dirty reads.
Humm... Not sure what to make of that comment. Have you ever
experimented with lock-free algorithms?
Why is it on topic?
If "lock-free algorithms" is on topic, why just turn off multi-tasking?
I am not exactly sure what you mean by your question wrt "why just turn
off multi-tasking"? Just use a single thread in your program?
Yes, early threads are actually a single thread, where lock is not necessary.

This remind me of a problem of the 'language'. Why we can't say:

thread void f(Arg arg1); // 'thread' is keyword

instead of lots of "weird" syntax, if we want to talk about "language"?
Chris M. Thomasson
2024-11-08 22:09:15 UTC
Permalink
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
On Fri, 08 Nov 2024 14:48:16 GMT
Post by Scott Lurndal
Post by Lynn McGuire
Post by jseigh
...
Post by jseigh
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance.  I don't think will
solve all the issues they think it will.  I can come up
with some pretty trivial examples that will break their
proposed solutions.  I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem.  Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues.  Kind of hard
to take the pointer provenance problem seriously.
Joe Seigh
What is the ABA problem ?
Lynn
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist. Why would anyone expect non
synchronised RW memory access to work? The exact same problem occurs
in databases with dirty reads.
Humm... Not sure what to make of that comment. Have you ever
experimented with lock-free algorithms?
Why is it on topic?
If "lock-free algorithms" is on topic, why just turn off multi-tasking?
I am not exactly sure what you mean by your question wrt "why just turn
off multi-tasking"? Just use a single thread in your program?
Yes, early threads are actually a single thread, where lock is not necessary.
I am not sure what you mean by "early threads". Can you clarify a bit?
Thanks.
Post by wij
thread void f(Arg arg1); // 'thread' is keyword
instead of lots of "weird" syntax, if we want to talk about "language"?
C++ threading is fairly "flexible", well, imho. Wrt C11 threads its akin
to PThreads. Well, minus the fine grain control we have wrt the "newer"
standards... C++/C 11 and such. The DWCAS issue aside for a moment, its
not all that bad.
wij
2024-11-08 22:35:45 UTC
Permalink
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
On Fri, 08 Nov 2024 14:48:16 GMT
Post by Scott Lurndal
Post by Lynn McGuire
Post by jseigh
...
Post by jseigh
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance.  I don't think will
solve all the issues they think it will.  I can come up
with some pretty trivial examples that will break their
proposed solutions.  I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem.  Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues.  Kind of hard
to take the pointer provenance problem seriously.
Joe Seigh
What is the ABA problem ?
Lynn
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist. Why would anyone expect non
synchronised RW memory access to work? The exact same problem occurs
in databases with dirty reads.
Humm... Not sure what to make of that comment. Have you ever
experimented with lock-free algorithms?
Why is it on topic?
If "lock-free algorithms" is on topic, why just turn off multi-tasking?
I am not exactly sure what you mean by your question wrt "why just turn
off multi-tasking"? Just use a single thread in your program?
Yes, early threads are actually a single thread, where lock is not necessary.
I am not sure what you mean by "early threads". Can you clarify a bit?
Thanks.
By early, I mean in DOS days. There was also such thread in Linux, I think it
is called Cooperative multitasking https://en.wikipedia.org/wiki/Cooperative_multitasking
Post by Chris M. Thomasson
Post by wij
thread void f(Arg arg1);      // 'thread' is keyword
instead of lots of "weird" syntax, if we want to talk about "language"?
C++ threading is fairly "flexible", well, imho. Wrt C11 threads its akin
to PThreads. Well, minus the fine grain control we have wrt the "newer"
standards... C++/C 11 and such. The DWCAS issue aside for a moment, its
not all that bad.
If so, use pthread to invent what you want, in stead of too many 'weird' modifications.
All are confined in your source. it should be easier to manage and less work and errors.
Chris M. Thomasson
2024-11-08 22:37:04 UTC
Permalink
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
On Fri, 08 Nov 2024 14:48:16 GMT
Post by Scott Lurndal
Post by Lynn McGuire
Post by jseigh
...
Post by jseigh
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance.  I don't think will
solve all the issues they think it will.  I can come up
with some pretty trivial examples that will break their
proposed solutions.  I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem.  Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues.  Kind of hard
to take the pointer provenance problem seriously.
Joe Seigh
What is the ABA problem ?
Lynn
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist. Why would anyone expect non
synchronised RW memory access to work? The exact same problem occurs
in databases with dirty reads.
Humm... Not sure what to make of that comment. Have you ever
experimented with lock-free algorithms?
Why is it on topic?
If "lock-free algorithms" is on topic, why just turn off multi-tasking?
I am not exactly sure what you mean by your question wrt "why just turn
off multi-tasking"? Just use a single thread in your program?
Yes, early threads are actually a single thread, where lock is not necessary.
I am not sure what you mean by "early threads". Can you clarify a bit?
Thanks.
By early, I mean in DOS days. There was also such thread in Linux, I think it
is called Cooperative multitasking https://en.wikipedia.org/wiki/Cooperative_multitasking
Post by Chris M. Thomasson
Post by wij
thread void f(Arg arg1);      // 'thread' is keyword
instead of lots of "weird" syntax, if we want to talk about "language"?
C++ threading is fairly "flexible", well, imho. Wrt C11 threads its akin
to PThreads. Well, minus the fine grain control we have wrt the "newer"
standards... C++/C 11 and such. The DWCAS issue aside for a moment, its
not all that bad.
If so, use pthread to invent what you want, in stead of too many 'weird' modifications.
All are confined in your source. it should be easier to manage and less work and errors.
pthreads does not provide standard membars and atomics... C/C++11 does.
wij
2024-11-08 22:47:27 UTC
Permalink
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
On Fri, 08 Nov 2024 14:48:16 GMT
Post by Scott Lurndal
Post by Lynn McGuire
Post by jseigh
...
Post by jseigh
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance.  I don't think will
solve all the issues they think it will.  I can come up
with some pretty trivial examples that will break their
proposed solutions.  I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem.  Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues.  Kind of hard
to take the pointer provenance problem seriously.
Joe Seigh
What is the ABA problem ?
Lynn
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist. Why would anyone expect non
synchronised RW memory access to work? The exact same problem occurs
in databases with dirty reads.
Humm... Not sure what to make of that comment. Have you ever
experimented with lock-free algorithms?
Why is it on topic?
If "lock-free algorithms" is on topic, why just turn off multi-tasking?
I am not exactly sure what you mean by your question wrt "why just turn
off multi-tasking"? Just use a single thread in your program?
Yes, early threads are actually a single thread, where lock is not necessary.
I am not sure what you mean by "early threads". Can you clarify a bit?
Thanks.
By early, I mean in DOS days. There was also such thread in Linux, I think it
is called Cooperative multitasking https://en.wikipedia.org/wiki/Cooperative_multitasking
Post by Chris M. Thomasson
Post by wij
thread void f(Arg arg1);      // 'thread' is keyword
instead of lots of "weird" syntax, if we want to talk about "language"?
C++ threading is fairly "flexible", well, imho. Wrt C11 threads its akin
to PThreads. Well, minus the fine grain control we have wrt the "newer"
standards... C++/C 11 and such. The DWCAS issue aside for a moment, its
not all that bad.
If so, use pthread to invent what you want, in stead of too many 'weird' modifications.
All are confined in your source. it should be easier to manage and less work and errors.
pthreads does not provide standard membars and atomics... C/C++11 does.
I don't use std::atomic. I don't have memory I need it.
But I think using std::atomic and pthread is compatible (there might be 'language' problems
I don't know. Or it might be solvable).
Chris M. Thomasson
2024-11-08 22:58:15 UTC
Permalink
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
On Fri, 08 Nov 2024 14:48:16 GMT
Post by Scott Lurndal
Post by Lynn McGuire
Post by jseigh
...
Post by jseigh
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance.  I don't think will
solve all the issues they think it will.  I can come up
with some pretty trivial examples that will break their
proposed solutions.  I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem.  Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues.  Kind of hard
to take the pointer provenance problem seriously.
Joe Seigh
What is the ABA problem ?
Lynn
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist. Why would anyone expect non
synchronised RW memory access to work? The exact same problem occurs
in databases with dirty reads.
Humm... Not sure what to make of that comment. Have you ever
experimented with lock-free algorithms?
Why is it on topic?
If "lock-free algorithms" is on topic, why just turn off multi-tasking?
I am not exactly sure what you mean by your question wrt "why just turn
off multi-tasking"? Just use a single thread in your program?
Yes, early threads are actually a single thread, where lock is not necessary.
I am not sure what you mean by "early threads". Can you clarify a bit?
Thanks.
By early, I mean in DOS days. There was also such thread in Linux, I think it
is called Cooperative multitasking https://en.wikipedia.org/wiki/Cooperative_multitasking
Post by Chris M. Thomasson
Post by wij
thread void f(Arg arg1);      // 'thread' is keyword
instead of lots of "weird" syntax, if we want to talk about "language"?
C++ threading is fairly "flexible", well, imho. Wrt C11 threads its akin
to PThreads. Well, minus the fine grain control we have wrt the "newer"
standards... C++/C 11 and such. The DWCAS issue aside for a moment, its
not all that bad.
If so, use pthread to invent what you want, in stead of too many 'weird' modifications.
All are confined in your source. it should be easier to manage and less work and errors.
pthreads does not provide standard membars and atomics... C/C++11 does.
I don't use std::atomic. I don't have memory I need it.
But I think using std::atomic and pthread is compatible (there might be 'language' problems
I don't know. Or it might be solvable).
Well, it might work wrt using std::atomic with pthreads. But, keep in
mind that Pthreads does not know shit about std::atomic and vise versa.
wij
2024-11-08 23:09:00 UTC
Permalink
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
On Fri, 08 Nov 2024 14:48:16 GMT
Post by Scott Lurndal
Post by Lynn McGuire
Post by jseigh
...
Post by jseigh
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance.  I don't think will
solve all the issues they think it will.  I can come up
with some pretty trivial examples that will break their
proposed solutions.  I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem.  Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues.  Kind of hard
to take the pointer provenance problem seriously.
Joe Seigh
What is the ABA problem ?
Lynn
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist. Why would anyone expect non
synchronised RW memory access to work? The exact same problem occurs
in databases with dirty reads.
Humm... Not sure what to make of that comment. Have you ever
experimented with lock-free algorithms?
Why is it on topic?
If "lock-free algorithms" is on topic, why just turn off multi-tasking?
I am not exactly sure what you mean by your question wrt "why just turn
off multi-tasking"? Just use a single thread in your program?
Yes, early threads are actually a single thread, where lock is not necessary.
I am not sure what you mean by "early threads". Can you clarify a bit?
Thanks.
By early, I mean in DOS days. There was also such thread in Linux, I think it
is called Cooperative multitasking https://en.wikipedia.org/wiki/Cooperative_multitasking
Post by Chris M. Thomasson
Post by wij
thread void f(Arg arg1);      // 'thread' is keyword
instead of lots of "weird" syntax, if we want to talk about "language"?
C++ threading is fairly "flexible", well, imho. Wrt C11 threads its akin
to PThreads. Well, minus the fine grain control we have wrt the "newer"
standards... C++/C 11 and such. The DWCAS issue aside for a moment, its
not all that bad.
If so, use pthread to invent what you want, in stead of too many 'weird' modifications.
All are confined in your source. it should be easier to manage and less work and errors.
pthreads does not provide standard membars and atomics... C/C++11 does.
I don't use std::atomic. I don't have memory I need it.
But I think using std::atomic and pthread is compatible (there might be 'language' problems
I don't know. Or it might be solvable).
Well, it might work wrt using std::atomic with pthreads. But, keep in
mind that Pthreads does not know shit about std::atomic and vise versa.
As said I don't know std::atomic. But I know std::thread is a more abstract model which
incorporates the functions of pthread. C++ in pthread is equivalent to C in pthread.
C++ cannot behave differently.
Chris M. Thomasson
2024-11-08 23:35:15 UTC
Permalink
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
On Fri, 08 Nov 2024 14:48:16 GMT
Post by Scott Lurndal
Post by Lynn McGuire
Post by jseigh
...
Post by jseigh
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance.  I don't think will
solve all the issues they think it will.  I can come up
with some pretty trivial examples that will break their
proposed solutions.  I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem.  Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues.  Kind of hard
to take the pointer provenance problem seriously.
Joe Seigh
What is the ABA problem ?
Lynn
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist. Why would anyone expect non
synchronised RW memory access to work? The exact same problem occurs
in databases with dirty reads.
Humm... Not sure what to make of that comment. Have you ever
experimented with lock-free algorithms?
Why is it on topic?
If "lock-free algorithms" is on topic, why just turn off multi-tasking?
I am not exactly sure what you mean by your question wrt "why just turn
off multi-tasking"? Just use a single thread in your program?
Yes, early threads are actually a single thread, where lock is not necessary.
I am not sure what you mean by "early threads". Can you clarify a bit?
Thanks.
By early, I mean in DOS days. There was also such thread in Linux, I think it
is called Cooperative multitasking https://en.wikipedia.org/wiki/Cooperative_multitasking
Post by Chris M. Thomasson
Post by wij
thread void f(Arg arg1);      // 'thread' is keyword
instead of lots of "weird" syntax, if we want to talk about "language"?
C++ threading is fairly "flexible", well, imho. Wrt C11 threads its akin
to PThreads. Well, minus the fine grain control we have wrt the "newer"
standards... C++/C 11 and such. The DWCAS issue aside for a moment, its
not all that bad.
If so, use pthread to invent what you want, in stead of too many 'weird' modifications.
All are confined in your source. it should be easier to manage and less work and errors.
pthreads does not provide standard membars and atomics... C/C++11 does.
I don't use std::atomic. I don't have memory I need it.
But I think using std::atomic and pthread is compatible (there might be 'language' problems
I don't know. Or it might be solvable).
Well, it might work wrt using std::atomic with pthreads. But, keep in
mind that Pthreads does not know shit about std::atomic and vise versa.
As said I don't know std::atomic. But I know std::thread is a more abstract model which
incorporates the functions of pthread. C++ in pthread is equivalent to C in pthread.
C++ cannot behave differently.
The fun part about std::atomic and std::thread is that they are all in
one standard. POSIX requires a compliant compiler and system. Iirc,
std::atomic is not 100% guaranteed to work with PThreads. It does with
std::threads...
Scott Lurndal
2024-11-08 23:50:37 UTC
Permalink
Post by Chris M. Thomasson
The fun part about std::atomic and std::thread is that they are all in
one standard. POSIX requires a compliant compiler and system. Iirc,
std::atomic is not 100% guaranteed to work with PThreads. It does with
std::threads...
If you're using pthreads, use POSIX synchronization APIs. If you're using
C/C++ standard threads, use synchronization APIs defined by the standard.

It's highly likely that on linux/unix systems, both sets of APIs
are implemented using the same operating system primitives.
Chris M. Thomasson
2024-11-09 02:11:48 UTC
Permalink
Post by Scott Lurndal
Post by Chris M. Thomasson
The fun part about std::atomic and std::thread is that they are all in
one standard. POSIX requires a compliant compiler and system. Iirc,
std::atomic is not 100% guaranteed to work with PThreads. It does with
std::threads...
If you're using pthreads, use POSIX synchronization APIs.
Agreed. It's likely that std::atomic can be used in conjunction, but
then again I am not 100% sure on that. Does the "contract" hold between
std::atomic std::memory_order, ect... with POSIX threads? We know it
does with std::thread and friends.
Post by Scott Lurndal
If you're using
C/C++ standard threads, use synchronization APIs defined by the standard.
Agreed again.
Post by Scott Lurndal
It's highly likely that on linux/unix systems, both sets of APIs
are implemented using the same operating system primitives.
Indeed.
Chris M. Thomasson
2024-11-08 22:39:28 UTC
Permalink
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
On Fri, 08 Nov 2024 14:48:16 GMT
Post by Scott Lurndal
Post by Lynn McGuire
Post by jseigh
...
Post by jseigh
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance.  I don't think will
solve all the issues they think it will.  I can come up
with some pretty trivial examples that will break their
proposed solutions.  I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem.  Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues.  Kind of hard
to take the pointer provenance problem seriously.
Joe Seigh
What is the ABA problem ?
Lynn
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist. Why would anyone expect non
synchronised RW memory access to work? The exact same problem occurs
in databases with dirty reads.
Humm... Not sure what to make of that comment. Have you ever
experimented with lock-free algorithms?
Why is it on topic?
If "lock-free algorithms" is on topic, why just turn off multi-tasking?
I am not exactly sure what you mean by your question wrt "why just turn
off multi-tasking"? Just use a single thread in your program?
Yes, early threads are actually a single thread, where lock is not necessary.
I am not sure what you mean by "early threads". Can you clarify a bit?
Thanks.
By early, I mean in DOS days. There was also such thread in Linux, I think it
is called Cooperative multitasking https://en.wikipedia.org/wiki/Cooperative_multitasking
Post by Chris M. Thomasson
Post by wij
thread void f(Arg arg1);      // 'thread' is keyword
instead of lots of "weird" syntax, if we want to talk about "language"?
C++ threading is fairly "flexible", well, imho. Wrt C11 threads its akin
to PThreads. Well, minus the fine grain control we have wrt the "newer"
standards... C++/C 11 and such. The DWCAS issue aside for a moment, its
not all that bad.
If so, use pthread to invent what you want, in stead of too many 'weird' modifications.
All are confined in your source. it should be easier to manage and less work and errors.
I used to use Pthreads all the time, and resort to asm for the lock-free
bits... They were for pre C/C++11 impls. The damn DWCAS issue is
annoying to say the least!
wij
2024-11-08 22:58:17 UTC
Permalink
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
On Fri, 08 Nov 2024 14:48:16 GMT
Post by Scott Lurndal
Post by Lynn McGuire
Post by jseigh
...
Post by jseigh
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance.  I don't think will
solve all the issues they think it will.  I can come up
with some pretty trivial examples that will break their
proposed solutions.  I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem.  Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues.  Kind of hard
to take the pointer provenance problem seriously.
Joe Seigh
What is the ABA problem ?
Lynn
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist. Why would anyone expect non
synchronised RW memory access to work? The exact same problem occurs
in databases with dirty reads.
Humm... Not sure what to make of that comment. Have you ever
experimented with lock-free algorithms?
Why is it on topic?
If "lock-free algorithms" is on topic, why just turn off multi-tasking?
I am not exactly sure what you mean by your question wrt "why just turn
off multi-tasking"? Just use a single thread in your program?
Yes, early threads are actually a single thread, where lock is not necessary.
I am not sure what you mean by "early threads". Can you clarify a bit?
Thanks.
By early, I mean in DOS days. There was also such thread in Linux, I think it
is called Cooperative multitasking https://en.wikipedia.org/wiki/Cooperative_multitasking
Post by Chris M. Thomasson
Post by wij
thread void f(Arg arg1);      // 'thread' is keyword
instead of lots of "weird" syntax, if we want to talk about "language"?
C++ threading is fairly "flexible", well, imho. Wrt C11 threads its akin
to PThreads. Well, minus the fine grain control we have wrt the "newer"
standards... C++/C 11 and such. The DWCAS issue aside for a moment, its
not all that bad.
If so, use pthread to invent what you want, in stead of too many 'weird' modifications.
All are confined in your source. it should be easier to manage and less work and errors.
I used to use Pthreads all the time, and resort to asm for the lock-free
bits... They were for pre C/C++11 impls. The damn DWCAS issue is
annoying to say the least!
Sound like a good reason to invent your own Thread class.
At least, you will know every thing more concrete.
Chris M. Thomasson
2024-11-08 23:01:31 UTC
Permalink
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
On Fri, 08 Nov 2024 14:48:16 GMT
Post by Scott Lurndal
Post by Lynn McGuire
Post by jseigh
...
Post by jseigh
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance.  I don't think will
solve all the issues they think it will.  I can come up
with some pretty trivial examples that will break their
proposed solutions.  I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem.  Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues.  Kind of hard
to take the pointer provenance problem seriously.
Joe Seigh
What is the ABA problem ?
Lynn
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist. Why would anyone expect non
synchronised RW memory access to work? The exact same problem occurs
in databases with dirty reads.
Humm... Not sure what to make of that comment. Have you ever
experimented with lock-free algorithms?
Why is it on topic?
If "lock-free algorithms" is on topic, why just turn off multi-tasking?
I am not exactly sure what you mean by your question wrt "why just turn
off multi-tasking"? Just use a single thread in your program?
Yes, early threads are actually a single thread, where lock is not necessary.
I am not sure what you mean by "early threads". Can you clarify a bit?
Thanks.
By early, I mean in DOS days. There was also such thread in Linux, I think it
is called Cooperative multitasking https://en.wikipedia.org/wiki/Cooperative_multitasking
Post by Chris M. Thomasson
Post by wij
thread void f(Arg arg1);      // 'thread' is keyword
instead of lots of "weird" syntax, if we want to talk about "language"?
C++ threading is fairly "flexible", well, imho. Wrt C11 threads its akin
to PThreads. Well, minus the fine grain control we have wrt the "newer"
standards... C++/C 11 and such. The DWCAS issue aside for a moment, its
not all that bad.
If so, use pthread to invent what you want, in stead of too many 'weird' modifications.
All are confined in your source. it should be easier to manage and less work and errors.
I used to use Pthreads all the time, and resort to asm for the lock-free
bits... They were for pre C/C++11 impls. The damn DWCAS issue is
annoying to say the least!
Sound like a good reason to invent your own Thread class.
At least, you will know every thing more concrete.
Well, wrt a thread class, just be sure to avoid calling into the thread
logic before the ctor of your thread class is 100% completed. I have had
to debug some really nasty bugs that dealt with that specific scenario.
Yikes!
wij
2024-11-08 23:13:45 UTC
Permalink
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
On Fri, 08 Nov 2024 14:48:16 GMT
Post by Scott Lurndal
Post by Lynn McGuire
Post by jseigh
...
Post by jseigh
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance.  I don't think will
solve all the issues they think it will.  I can come up
with some pretty trivial examples that will break their
proposed solutions.  I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem.  Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues.  Kind of hard
to take the pointer provenance problem seriously.
Joe Seigh
What is the ABA problem ?
Lynn
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist. Why would anyone expect non
synchronised RW memory access to work? The exact same problem occurs
in databases with dirty reads.
Humm... Not sure what to make of that comment. Have you ever
experimented with lock-free algorithms?
Why is it on topic?
If "lock-free algorithms" is on topic, why just turn off multi-tasking?
I am not exactly sure what you mean by your question wrt "why just turn
off multi-tasking"? Just use a single thread in your program?
Yes, early threads are actually a single thread, where lock is not necessary.
I am not sure what you mean by "early threads". Can you clarify a bit?
Thanks.
By early, I mean in DOS days. There was also such thread in Linux, I think it
is called Cooperative multitasking https://en.wikipedia.org/wiki/Cooperative_multitasking
Post by Chris M. Thomasson
Post by wij
thread void f(Arg arg1);      // 'thread' is keyword
instead of lots of "weird" syntax, if we want to talk about "language"?
C++ threading is fairly "flexible", well, imho. Wrt C11 threads its akin
to PThreads. Well, minus the fine grain control we have wrt the "newer"
standards... C++/C 11 and such. The DWCAS issue aside for a moment, its
not all that bad.
If so, use pthread to invent what you want, in stead of too many 'weird' modifications.
All are confined in your source. it should be easier to manage and less work and errors.
I used to use Pthreads all the time, and resort to asm for the lock-free
bits... They were for pre C/C++11 impls. The damn DWCAS issue is
annoying to say the least!
Sound like a good reason to invent your own Thread class.
At least, you will know every thing more concrete.
Well, wrt a thread class, just be sure to avoid calling into the thread
logic before the ctor of your thread class is 100% completed. I have had
to debug some really nasty bugs that dealt with that specific scenario.
Yikes!
I need examples to understand what you mean. I have not touched thread issues for many years
, but hope I can help.
Chris M. Thomasson
2024-11-08 23:40:49 UTC
Permalink
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
On Fri, 08 Nov 2024 14:48:16 GMT
Post by Scott Lurndal
Post by Lynn McGuire
Post by jseigh
...
Post by jseigh
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance.  I don't think will
solve all the issues they think it will.  I can come up
with some pretty trivial examples that will break their
proposed solutions.  I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem.  Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues.  Kind of hard
to take the pointer provenance problem seriously.
Joe Seigh
What is the ABA problem ?
Lynn
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist. Why would anyone expect non
synchronised RW memory access to work? The exact same problem occurs
in databases with dirty reads.
Humm... Not sure what to make of that comment. Have you ever
experimented with lock-free algorithms?
Why is it on topic?
If "lock-free algorithms" is on topic, why just turn off multi-tasking?
I am not exactly sure what you mean by your question wrt "why just turn
off multi-tasking"? Just use a single thread in your program?
Yes, early threads are actually a single thread, where lock is not necessary.
I am not sure what you mean by "early threads". Can you clarify a bit?
Thanks.
By early, I mean in DOS days. There was also such thread in Linux, I think it
is called Cooperative multitasking https://en.wikipedia.org/wiki/Cooperative_multitasking
Post by Chris M. Thomasson
Post by wij
thread void f(Arg arg1);      // 'thread' is keyword
instead of lots of "weird" syntax, if we want to talk about "language"?
C++ threading is fairly "flexible", well, imho. Wrt C11 threads its akin
to PThreads. Well, minus the fine grain control we have wrt the "newer"
standards... C++/C 11 and such. The DWCAS issue aside for a moment, its
not all that bad.
If so, use pthread to invent what you want, in stead of too many 'weird' modifications.
All are confined in your source. it should be easier to manage and less work and errors.
I used to use Pthreads all the time, and resort to asm for the lock-free
bits... They were for pre C/C++11 impls. The damn DWCAS issue is
annoying to say the least!
Sound like a good reason to invent your own Thread class.
At least, you will know every thing more concrete.
Well, wrt a thread class, just be sure to avoid calling into the thread
logic before the ctor of your thread class is 100% completed. I have had
to debug some really nasty bugs that dealt with that specific scenario.
Yikes!
I need examples to understand what you mean. I have not touched thread issues for many years
, but hope I can help.
iirc, it was a base class that called its pure virtual thread entry
function _before_ its derived class had a chance to fully complete its
ctor. It's been a while since I have encountered this nasty scenario.
Thank god.
wij
2024-11-09 00:19:19 UTC
Permalink
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
On Fri, 08 Nov 2024 14:48:16 GMT
Post by Scott Lurndal
Post by Lynn McGuire
Post by jseigh
...
Post by jseigh
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance.  I don't think will
solve all the issues they think it will.  I can come up
with some pretty trivial examples that will break their
proposed solutions.  I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem.  Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues.  Kind of hard
to take the pointer provenance problem seriously.
Joe Seigh
What is the ABA problem ?
Lynn
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist. Why would anyone expect non
synchronised RW memory access to work? The exact same problem occurs
in databases with dirty reads.
Humm... Not sure what to make of that comment. Have you ever
experimented with lock-free algorithms?
Why is it on topic?
If "lock-free algorithms" is on topic, why just turn off multi-tasking?
I am not exactly sure what you mean by your question wrt "why just turn
off multi-tasking"? Just use a single thread in your program?
Yes, early threads are actually a single thread, where lock is not necessary.
I am not sure what you mean by "early threads". Can you clarify a bit?
Thanks.
By early, I mean in DOS days. There was also such thread in Linux, I think it
is called Cooperative multitasking https://en.wikipedia.org/wiki/Cooperative_multitasking
Post by Chris M. Thomasson
Post by wij
thread void f(Arg arg1);      // 'thread' is keyword
instead of lots of "weird" syntax, if we want to talk about "language"?
C++ threading is fairly "flexible", well, imho. Wrt C11 threads its akin
to PThreads. Well, minus the fine grain control we have wrt the "newer"
standards... C++/C 11 and such. The DWCAS issue aside for a moment, its
not all that bad.
If so, use pthread to invent what you want, in stead of too many 'weird' modifications.
All are confined in your source. it should be easier to manage and less work and errors.
I used to use Pthreads all the time, and resort to asm for the lock-free
bits... They were for pre C/C++11 impls. The damn DWCAS issue is
annoying to say the least!
Sound like a good reason to invent your own Thread class.
At least, you will know every thing more concrete.
Well, wrt a thread class, just be sure to avoid calling into the thread
logic before the ctor of your thread class is 100% completed. I have had
to debug some really nasty bugs that dealt with that specific scenario.
Yikes!
I need examples to understand what you mean. I have not touched thread issues for many years
, but hope I can help.
iirc, it was a base class that called its pure virtual thread entry
function _before_ its derived class had a chance to fully complete its
ctor. It's been a while since I have encountered this nasty scenario.
Thank god.
class BaseThread {
public:
BaseThread(Func func);
virtual ~BaseThread();
};

class Thread : BaseThread {
public:
Thread(Func func) {
// init vars.
::pthread_create(...func...); // the last line
};
// ....
}

The thread should be started in Thread (not in BaseThread), if I guess what you mean correctly.
Chris M. Thomasson
2024-11-09 02:15:39 UTC
Permalink
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by wij
Post by Chris M. Thomasson
Post by M***@DastartdlyHQ.org
On Fri, 08 Nov 2024 14:48:16 GMT
Post by Scott Lurndal
Post by Lynn McGuire
Post by jseigh
...
Post by jseigh
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance.  I don't think will
solve all the issues they think it will.  I can come up
with some pretty trivial examples that will break their
proposed solutions.  I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem.  Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues.  Kind of hard
to take the pointer provenance problem seriously.
Joe Seigh
What is the ABA problem ?
Lynn
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist. Why would anyone expect non
synchronised RW memory access to work? The exact same problem occurs
in databases with dirty reads.
Humm... Not sure what to make of that comment. Have you ever
experimented with lock-free algorithms?
Why is it on topic?
If "lock-free algorithms" is on topic, why just turn off multi-tasking?
I am not exactly sure what you mean by your question wrt "why just turn
off multi-tasking"? Just use a single thread in your program?
Yes, early threads are actually a single thread, where lock is not necessary.
I am not sure what you mean by "early threads". Can you clarify a bit?
Thanks.
By early, I mean in DOS days. There was also such thread in Linux, I think it
is called Cooperative multitasking https://en.wikipedia.org/wiki/Cooperative_multitasking
Post by Chris M. Thomasson
Post by wij
thread void f(Arg arg1);      // 'thread' is keyword
instead of lots of "weird" syntax, if we want to talk about "language"?
C++ threading is fairly "flexible", well, imho. Wrt C11 threads its akin
to PThreads. Well, minus the fine grain control we have wrt the "newer"
standards... C++/C 11 and such. The DWCAS issue aside for a moment, its
not all that bad.
If so, use pthread to invent what you want, in stead of too many 'weird' modifications.
All are confined in your source. it should be easier to manage and less work and errors.
I used to use Pthreads all the time, and resort to asm for the lock-free
bits... They were for pre C/C++11 impls. The damn DWCAS issue is
annoying to say the least!
Sound like a good reason to invent your own Thread class.
At least, you will know every thing more concrete.
Well, wrt a thread class, just be sure to avoid calling into the thread
logic before the ctor of your thread class is 100% completed. I have had
to debug some really nasty bugs that dealt with that specific scenario.
Yikes!
I need examples to understand what you mean. I have not touched thread issues for many years
, but hope I can help.
iirc, it was a base class that called its pure virtual thread entry
function _before_ its derived class had a chance to fully complete its
ctor. It's been a while since I have encountered this nasty scenario.
Thank god.
class BaseThread {
BaseThread(Func func);
virtual ~BaseThread();
};
class Thread : BaseThread {
Thread(Func func) {
// init vars.
::pthread_create(...func...); // the last line
};
// ....
}
You just have to make sure that the thread is created after class Thread
is ready for it. I have had to debug horror shows with threads created
in ctors before...
Post by wij
The thread should be started in Thread (not in BaseThread), if I guess what you mean correctly.
Basically, the general rule is that a thread should be started _after_
everything it needs to use has been fully initialized.
Scott Lurndal
2024-11-09 16:23:50 UTC
Permalink
Post by Chris M. Thomasson
Post by wij
class BaseThread {
BaseThread(Func func);
virtual ~BaseThread();
};
class Thread : BaseThread {
Thread(Func func) {
// init vars.
::pthread_create(...func...); // the last line
};
// ....
}
You just have to make sure that the thread is created after class Thread
is ready for it. I have had to debug horror shows with threads created
in ctors before...
It's really very simple. Use a two-phase approach. The run thread
is created and immediately waits on a condition variable. When the
most derived constructor completes initialization, it signals the
condition variable before running the virtual 'run' function.
Chris M. Thomasson
2024-11-09 20:42:58 UTC
Permalink
Post by Scott Lurndal
Post by Chris M. Thomasson
Post by wij
class BaseThread {
BaseThread(Func func);
virtual ~BaseThread();
};
class Thread : BaseThread {
Thread(Func func) {
// init vars.
::pthread_create(...func...); // the last line
};
// ....
}
You just have to make sure that the thread is created after class Thread
is ready for it. I have had to debug horror shows with threads created
in ctors before...
It's really very simple. Use a two-phase approach. The run thread
is created and immediately waits on a condition variable. When the
most derived constructor completes initialization, it signals the
condition variable before running the virtual 'run' function.
Humm... Why not just make sure everything a thread needs is fully
constructed before you "launch" it? No condvars, mutexes necessary. This
is only on thread creation.
Scott Lurndal
2024-11-09 23:23:32 UTC
Permalink
Post by Chris M. Thomasson
Post by Scott Lurndal
Post by Chris M. Thomasson
Post by wij
class BaseThread {
BaseThread(Func func);
virtual ~BaseThread();
};
class Thread : BaseThread {
Thread(Func func) {
// init vars.
::pthread_create(...func...); // the last line
};
// ....
}
You just have to make sure that the thread is created after class Thread
is ready for it. I have had to debug horror shows with threads created
in ctors before...
It's really very simple. Use a two-phase approach. The run thread
is created and immediately waits on a condition variable. When the
most derived constructor completes initialization, it signals the
condition variable before running the virtual 'run' function.
Humm... Why not just make sure everything a thread needs is fully
constructed before you "launch" it? No condvars, mutexes necessary. This
is only on thread creation.
The idea is that your class inherits from the thread class ahead of
any other classes which encapsulates the thread creation in the
thread class constructor, which is the natural place to look for
it.
Paavo Helde
2024-11-10 09:00:32 UTC
Permalink
Post by Scott Lurndal
Post by Chris M. Thomasson
Post by Scott Lurndal
Post by Chris M. Thomasson
Post by wij
class BaseThread {
BaseThread(Func func);
virtual ~BaseThread();
};
class Thread : BaseThread {
Thread(Func func) {
// init vars.
::pthread_create(...func...); // the last line
};
// ....
}
You just have to make sure that the thread is created after class Thread
is ready for it. I have had to debug horror shows with threads created
in ctors before...
It's really very simple. Use a two-phase approach. The run thread
is created and immediately waits on a condition variable. When the
most derived constructor completes initialization, it signals the
condition variable before running the virtual 'run' function.
Humm... Why not just make sure everything a thread needs is fully
constructed before you "launch" it? No condvars, mutexes necessary. This
is only on thread creation.
The idea is that your class inherits from the thread class ahead of
any other classes which encapsulates the thread creation in the
thread class constructor, which is the natural place to look for
it.
This would require a delayed startup as you describe earlier, which
makes things more complicated and cumbersome. I have adopted another way:

1. Never derive from std::thread.

2. If std::thread is a class member, it must be the last member.

3. Start it up by passing a lambda which calls the thread function
with needed parameters explicitly, no need to design a virtual Run()
function with a fixed rigid signature.
Chris M. Thomasson
2024-11-13 00:56:10 UTC
Permalink
Post by Paavo Helde
Post by Scott Lurndal
Post by Chris M. Thomasson
Post by Chris M. Thomasson
Post by wij
class BaseThread {
       BaseThread(Func func);
       virtual ~BaseThread();
};
class Thread : BaseThread {
       Thread(Func func) {
          // init vars.
          ::pthread_create(...func...);  // the last line
       };
       // ....
}
You just have to make sure that the thread is created after class Thread
is ready for it. I have had to debug horror shows with threads created
in ctors before...
It's really very simple.   Use a two-phase approach.   The run thread
is created and immediately waits on a condition variable.   When the
most derived constructor completes initialization, it signals the
condition variable before running the virtual 'run' function.
Humm... Why not just make sure everything a thread needs is fully
constructed before you "launch" it? No condvars, mutexes necessary. This
is only on thread creation.
The idea is that your class inherits from the thread class ahead of
any other classes which encapsulates the thread creation in the
thread class constructor, which is the natural place to look for
it.
This would require a delayed startup as you describe earlier, which
   1. Never derive from std::thread.
   2. If std::thread is a class member, it must be the last member.
   3. Start it up by passing a lambda which calls the thread function
with needed parameters explicitly, no need to design a virtual Run()
function with a fixed rigid signature.
Ditto! Hyper similar thought crossed my mind as well Paavo. Strange! ;^o
Chris M. Thomasson
2024-11-13 00:59:49 UTC
Permalink
Post by Chris M. Thomasson
Post by Paavo Helde
Post by Scott Lurndal
Post by Chris M. Thomasson
Post by Chris M. Thomasson
Post by wij
class BaseThread {
       BaseThread(Func func);
       virtual ~BaseThread();
};
class Thread : BaseThread {
       Thread(Func func) {
          // init vars.
          ::pthread_create(...func...);  // the last line
       };
       // ....
}
You just have to make sure that the thread is created after class Thread
is ready for it. I have had to debug horror shows with threads created
in ctors before...
It's really very simple.   Use a two-phase approach.   The run thread
is created and immediately waits on a condition variable.   When the
most derived constructor completes initialization, it signals the
condition variable before running the virtual 'run' function.
Humm... Why not just make sure everything a thread needs is fully
constructed before you "launch" it? No condvars, mutexes necessary. This
is only on thread creation.
The idea is that your class inherits from the thread class ahead of
any other classes which encapsulates the thread creation in the
thread class constructor, which is the natural place to look for
it.
This would require a delayed startup as you describe earlier, which
    1. Never derive from std::thread.
    2. If std::thread is a class member, it must be the last member.
    3. Start it up by passing a lambda which calls the thread function
with needed parameters explicitly, no need to design a virtual Run()
function with a fixed rigid signature.
Ditto! Hyper similar thought crossed my mind as well Paavo. Strange! ;^o
Say a thread needs to use a "local _but_ global" queue and a stack.
Well, those (the queue and stack) better be constructed and ready to
roll, before any damn thread can access them at all! Just, well, imvho
that is. ;^o

I say local but global wrt some of my example code that puts the shared
data in the main thread.

Any Thoughts on this matter? Shit.
Chris M. Thomasson
2024-11-13 01:05:48 UTC
Permalink
Post by Chris M. Thomasson
Post by Chris M. Thomasson
Post by Paavo Helde
Post by Scott Lurndal
Post by Chris M. Thomasson
Post by Chris M. Thomasson
Post by wij
class BaseThread {
       BaseThread(Func func);
       virtual ~BaseThread();
};
class Thread : BaseThread {
       Thread(Func func) {
          // init vars.
          ::pthread_create(...func...);  // the last line
       };
       // ....
}
You just have to make sure that the thread is created after class Thread
is ready for it. I have had to debug horror shows with threads created
in ctors before...
It's really very simple.   Use a two-phase approach.   The run thread
is created and immediately waits on a condition variable.   When the
most derived constructor completes initialization, it signals the
condition variable before running the virtual 'run' function.
Humm... Why not just make sure everything a thread needs is fully
constructed before you "launch" it? No condvars, mutexes necessary. This
is only on thread creation.
The idea is that your class inherits from the thread class ahead of
any other classes which encapsulates the thread creation in the
thread class constructor, which is the natural place to look for
it.
This would require a delayed startup as you describe earlier, which
    1. Never derive from std::thread.
    2. If std::thread is a class member, it must be the last member.
    3. Start it up by passing a lambda which calls the thread
function with needed parameters explicitly, no need to design a
virtual Run() function with a fixed rigid signature.
Ditto! Hyper similar thought crossed my mind as well Paavo. Strange! ;^o
Say a thread needs to use a "local _but_ global" queue and a stack.
Well, those (the queue and stack) better be constructed and ready to
roll, before any damn thread can access them at all! Just, well, imvho
that is. ;^o
I say local but global wrt some of my example code that puts the shared
data in the main thread.
Any Thoughts on this matter? Shit.
local but global? lol! What do you think. shared is global in an odd
sense. But its contained in mains local context, so to speak? Weasel
words, or kind of okay?
_____________
int
main()
{
std::cout << "ct_proxy_collector testing 123...\n";
std::cout << "_________________________________\n\n" << std::endl;

{
ct_shared shared;

{
std::thread threads[CT_THREAD_N];

std::cout << "Launching threads and processing...\n";
std::cout << "____________________\n" << std::endl;

{
{
// Create worker threads...
for (unsigned long i = 0; i < CT_THREAD_WORKERS_N; ++i)
{
threads[i] = std::thread(ct_worker_thread,
std::ref(shared), i);
}

_____________
M***@dastardlyhq.com
2024-11-09 12:01:06 UTC
Permalink
On Fri, 8 Nov 2024 15:40:49 -0800
Post by wij
Post by wij
I need examples to understand what you mean. I have not touched thread
issues for many years
Post by wij
, but hope I can help.
iirc, it was a base class that called its pure virtual thread entry
function _before_ its derived class had a chance to fully complete its
ctor. It's been a while since I have encountered this nasty scenario.
Its such an old and well known C++ problem it often comes up in interview
questions.
M***@dastardlyhq.com
2024-11-09 12:01:13 UTC
Permalink
On Fri, 8 Nov 2024 14:39:28 -0800
Post by wij
Post by wij
If so, use pthread to invent what you want, in stead of too many 'weird'
modifications.
Post by wij
All are confined in your source. it should be easier to manage and less work
and errors.
I used to use Pthreads all the time, and resort to asm for the lock-free
bits... They were for pre C/C++11 impls. The damn DWCAS issue is
Using assembler is not very portable (and not even backwards compatible with
older CPU generations depending on op codes) and future maintenance devs won't
thank you for it.
Chris M. Thomasson
2024-11-09 20:50:21 UTC
Permalink
Post by M***@dastardlyhq.com
On Fri, 8 Nov 2024 14:39:28 -0800
Post by wij
Post by wij
If so, use pthread to invent what you want, in stead of too many 'weird'
modifications.
Post by wij
All are confined in your source. it should be easier to manage and less work
and errors.
I used to use Pthreads all the time, and resort to asm for the lock-
free bits... They were for pre C/C++11 impls. The damn DWCAS issue is
Using assembler is not very portable (and not even backwards compatible with
older CPU generations depending on op codes) and future maintenance devs
won't thank you for it.
It's not portable at all! Indeed. :^)

Fwiw, I used to use it (asm intel/sparc/ppc) for sensitive algorithms
way _before_ C/C++11 came out. Then, I started thinking about porting
them to the pure portable and new C/C++ std. It's a shame that DWCAS is
not fully available as always lock free on arch's that support it...
Shit happens. But, it should not be all that hard for the tormentors, or
should I say compiler vendors, of the std to support it.

If DWCAS is on an arch then C++ should say it's always lock-free.

Grrrrr!
Tim Rentsch
2024-11-04 14:59:14 UTC
Permalink
jseigh <***@xemaps.com> writes:

[...]
You create a new nullable attribute for pointers. That
would make the pointer behave like void* instead of T*.
You could move, copy, and compare, but you could not
dereference them. If you wanted to dereference them
you would have to apply a special not_null unary predicate
to them. What makes it special is the boolean result
is only valid inside a conditional expression. It's
not copyable or referencable. You could have 1 or
more of these in a conditional expression along with
ordinary predicates with the restriction that the
expression has to be formed such that if any of the
not_null terms are false, the expression has to
evaluate as false.
The other thing that makes not_null is that inside
if the conditional statements true blocks, the
nullable pointer gets it T* properties back, so
you can dereference it, but again only in the
true blocks. So for example
nullable T* p = &something;
T p2 = *p; // invalid, compiler thinks you are trying
// do dereference void*
not_null(p); // invalid, not inside conditional expression
if (not_null(p)
p2 = *p; // valid
else
p2 = *p; // invalid
Traversing a linked list would look like
T* p = head;
while (not_null(p)) {
...
p = p->next; // valid, inside while true block
}
not_null would look like
__predicate_bool not_null(T *&)
It would make a const copy of T*, test that,
cast to T*, use it for the true block.
So no NPEs possible for pointer with this
attribute.
A few comments.

An "attribute" should be placed like a qualifier, next
to the pointer, rather than before the type specifier.

The sense of the attribute should be "never null" rather
than "nullable". Ordinary pointers are nullable; what
is needed is a way to indicate that a particular pointer
(either a variable or the return value of a function) will
never be null.

I expect there are implications for pointers to never-null
pointers, but I haven't tried to work out what they need
to be. Example: 'T *nevernull *p;'. What are the rules
for assigning to p?

Ordinary pointers can (sometimes) be determined to be
non-null using data flow analysis (like what you say in
the followup post for the linked list example).

There is no need for not_null(). If we see

if(p){ ... }

or

while(p){ ... }

we know that p will not be null inside the controlled
statement (subject to change if there is an assignment
to p, per the data flow remark above).
jseigh
2024-11-30 15:03:26 UTC
Permalink
Post by Lynn McGuire
"Safe C++ is A new Proposal to Make C++ Memory-Safe"
   https://www.infoq.com/news/2024/10/safe-cpp-proposal/
"The goal of the Safe C++ proposal is extending C++ by defining a
superset of the language that can be used to write code with the strong
safety guarantees similarly to code written in Rust. The key to its
approach is introducing a new safe context where only a rigorously safe
subset of C++ is allowed."
"The Safe C++ proposal, set forth by Sean Baxter and Christian Mazakas,
originates from the growing awareness that C++ memory unsafety lies at
the root of a large part of vulnerabilities and memory exploits. The
only existing safe language, say Baxter and Mazakas, is Rust, but their
design differences limit interoperability, thus making it hard to
migrate from one language to the other. For example, Rust lacks function
overloading, templates, inheritance, and exceptions, while C++ lacks
traits, relocation, and borrow checking."
Lynn
I did figure out how to do Rust style locking in C++ while working on
some deferred reclamation stuff. It's fairly simple to implement.
I'm not masochistic enough to want to use it though.

Joe Seigh

Loading...