Friday, November 24, 2023

Digest for comp.lang.c++@googlegroups.com - 25 updates in 2 topics

Bonita Montero <Bonita.Montero@gmail.com>: Nov 24 05:26AM +0100

Am 23.11.2023 um 20:56 schrieb Scott Lurndal:
 
>>> std::atomic<size_t> r
 
>> The trick with my code
 
> That's enough to fail a job interview....
 
... with a nerd like you.
Bonita Montero <Bonita.Montero@gmail.com>: Nov 24 05:27AM +0100

Am 23.11.2023 um 21:32 schrieb Kaz Kylheku:
 
> BTW, is the C++ lambda too broken to access the r via lexical scoping?
> Why can't the APC just do "--r".
 
> I believe local functions in Pascal from 1971 can do this.
 
I already corrected that with my code and I guessed no one will notice
that here; usually I'm right with that.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 23 09:47PM -0800

On 11/23/2023 11:56 AM, Scott Lurndal wrote:
 
>>> std::atomic<size_t> r
 
>> The trick with my code
 
> That's enough to fail a job interview....
 
Wow, no shit Scott. Yikes!
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 23 09:53PM -0800

On 11/23/2023 8:26 PM, Bonita Montero wrote:
 
>>> The trick with my code
 
>> That's enough to fail a job interview....
 
> ... with a nerd like you.
 
Huh? What does that even mean? Really, humm... ;^o
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 23 09:55PM -0800

On 11/23/2023 8:27 PM, Bonita Montero wrote:
 
>> I believe local functions in Pascal from 1971 can do this.
 
> I already corrected that with my code and I guessed no one will notice
> that here; usually I'm right with that.
 
Usually, wrong, or always right? humm...
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 23 09:59PM -0800

On 11/23/2023 8:26 PM, Bonita Montero wrote:
 
>>> The trick with my code
 
>> That's enough to fail a job interview....
 
> ... with a nerd like you.
 
Do you secretly like nerds? https://youtu.be/7dP1Vp1E-bo
 
lol!
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 23 10:05PM -0800

On 11/23/2023 8:20 AM, Bonita Montero wrote:
>> that it wlll get the most recent value that has happened "before" the
>> read (as determined by memory order).
 
> ... and the read is atomic - even if the trivial object is 1kB in size.
 
humm.. Say, the read is from a word in memory. Define your trivial
object, POD, l2 cache line sized, and aligned on a l2 cache line
boundary? Are you refering to how certain arch works?
 
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 23 10:53PM -0800

On 11/23/2023 10:05 PM, Chris M. Thomasson wrote:
 
> humm.. Say, the read is from a word in memory. Define your trivial
> object, POD, l2 cache line sized, and aligned on a l2 cache line
> boundary? Are you refering to how certain arch works?
 
How many words in your cache lines, say l2?
 
Bonita Montero <Bonita.Montero@gmail.com>: Nov 24 08:53AM +0100

Am 24.11.2023 um 07:05 schrieb Chris M. Thomasson:
 
> humm.. Say, the read is from a word in memory. Define your trivial
> object, POD, l2 cache line sized, and aligned on a l2 cache line
> boundary? Are you refering to how certain arch works?
 
Read that:
https://stackoverflow.com/questions/61329240/what-is-the-difference-between-trivial-and-non-trivial-objects
Bonita Montero <Bonita.Montero@gmail.com>: Nov 24 08:57AM +0100

Am 23.11.2023 um 18:50 schrieb Richard Damon:
 
> there is no requirement to refetch the data if the code still has the
> old value around, and it hasn't been invalidated by possible memory
> ordering.
 
I don't believe that, think about an atomic flag that is periodically
polled. The compiler shouldn't cache that value.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 24 12:16AM -0800

On 11/23/2023 11:57 PM, Bonita Montero wrote:
>> ordering.
 
> I don't believe that, think about an atomic flag that is periodically
> polled. The compiler shouldn't cache that value.
 
std::atomic is going to work for such a flag. Depending on your setup,
it should be using std::memory_order_relaxed for the polling.
Bonita Montero <Bonita.Montero@gmail.com>: Nov 24 09:30AM +0100

Am 24.11.2023 um 09:16 schrieb Chris M. Thomasson:
 
> std::atomic is going to work for such a flag. Depending on your
> setup, it should be using std::memory_order_relaxed for the polling.
 
There's also atomic_flag, but it has some limitations over atomic_bool
that I've never used it. You can set it only in conjunction with an
atomic read and I never had a use for that. And this relies on a atomic
exchange, which costs a lot more than just a byte write.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 24 01:04AM -0800

On 11/24/2023 12:30 AM, Bonita Montero wrote:
> that I've never used it. You can set it only in conjunction with an
> atomic read and I never had a use for that. And this relies on a atomic
> exchange, which costs a lot more than just a byte write.
 
Fwiw, this flag should be aligned on a l2 cache line boundary, and
padded up to a l2 cache line size.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 24 01:05AM -0800

On 11/24/2023 1:04 AM, Chris M. Thomasson wrote:
>> exchange, which costs a lot more than just a byte write.
 
> Fwiw, this flag should be aligned on a l2 cache line boundary, and
> padded up to a l2 cache line size.
 
You can stuff a cache line with words, as long as you do not straddle a
cache line boundary... YIKES!
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 24 01:06AM -0800

On 11/23/2023 11:53 PM, Bonita Montero wrote:
>> boundary? Are you refering to how certain arch works?
 
> Read that:
> https://stackoverflow.com/questions/61329240/what-is-the-difference-between-trivial-and-non-trivial-objects
 
I know. Btw, what the hell happened to std::is_pod? ;^)
David Brown <david.brown@hesbynett.no>: Nov 24 10:08AM +0100

On 23/11/2023 20:55, Scott Lurndal wrote:
> is, and won't be affected of someone accidentially removes the
> volatile qualifier from the declaration of r.
 
> Works just fine in c++, too.
 
That is often my preference too, since it is the access that is
"volatile" - a "volatile object" is simply one for which all accesses
are "volatile".
 
For the pedants, it might be worth noting that the "cast to pointer to
volatile" technique of ACCESS_ONCE is not actually guaranteed to be
treated as a volatile access in C until C17/C18 when the wording was
changed to talk about accesses via "volatile lvalues" rather than
accesses to objects declared as volatile. (When the topic was discussed
by the committee, everyone agreed that all known compiler vendors
treated "cast to pointer to volatile" accesses as volatile, so the
change was a formality rather than any practical difference.) I don't
know if and when this change was added to C++.
Bonita Montero <Bonita.Montero@gmail.com>: Nov 24 10:10AM +0100

Am 24.11.2023 um 10:06 schrieb Chris M. Thomasson:
 
>> Read that:
>> https://stackoverflow.com/questions/61329240/what-is-the-difference-between-trivial-and-non-trivial-objects
 
> I know. Btw, what the hell happened to std::is_pod? ;^)
 
PODs are also trivial but go beyond since you can copy them
with a memcpy():
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 24 01:14AM -0800

On 11/23/2023 8:20 AM, Bonita Montero wrote:
>> that it wlll get the most recent value that has happened "before" the
>> read (as determined by memory order).
 
> ... and the read is atomic - even if the trivial object is 1kB in size.
 
How is that read atomic with 1kb of data? On what arch?
 
David Brown <david.brown@hesbynett.no>: Nov 24 10:23AM +0100

On 23/11/2023 18:50, Richard Damon wrote:
> need to consider possible action by other "threads" but only as far a
> constrained by memory order, so two reads in the same ordering "slot"
> are not forced.
 
That is exactly how I see it (I also do not consider myself an expert in
this area). I cannot see any requirement in the description of the
execution, covering sequencing, ordering, "happens before", and all the
rest, that suggests that the number of atomic accesses, or their order
amongst each other, or their order with respect to volatile accesses or
non-volatile accesses, is forced to follow the source code except where
the atomics have specific sequencing. Atomic accesses are not
"volatile" - they are not, in themselves, "observable behaviour".
 
Because the the sequencing requirements for atomics depends partly on
things happening in other threads, compilers are much more limited in
how they can re-order or otherwise optimise atomic accesses than they
are for normal accesses (unless the compiler knows all about the other
threads too!). Compilers must be pessimistic about optimisation. But
for certain simple cases, such as multiple neighbouring atomic reads of
the same address or multiple neighbouring writes to the same address, I
can't see any reason why they cannot be combined.
 
(Again, I am not an expert here - and I will be happy to be corrected.
They say the best way to learn something on the internet is not by
asking questions, but by writing something that is wrong!)
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 23 09:35PM -0800

On 11/23/2023 3:14 PM, Michael S wrote:
 
>> Today, Microsoft provides condition variables.
 
> Which, I would guess, never used by 99.9% of programs that were not
> ported to Windows from some other platform.
 
Fwiw, check this out:
 
https://sourceware.org/pthreads-win32/
 
;^)
 
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 23 09:38PM -0800

On 11/21/2023 1:25 AM, Bonita Montero wrote:
> Am 20.11.2023 um 21:18 schrieb Chris M. Thomasson:
 
>> Did you read that article on MSDN as well? Iirc, its around 20 years old.
 
> Has WFMO ever changed ?
 
No, I don't think so.. The interesting aspect was about trying to avoid
starvation the the wait array wrt the IOCP vs Event contest. So, we were
advised to randomize and/or shift the positions wrt the event side wrt WFMO.
Bonita Montero <Bonita.Montero@gmail.com>: Nov 24 08:56AM +0100

Am 24.11.2023 um 06:38 schrieb Chris M. Thomasson:
 
> starvation the the wait array wrt the IOCP vs Event contest. So, we were
> advised to randomize and/or shift the positions wrt the event side wrt
> WFMO.
 
You officially can't wait for an IOCP handle with WFMO, although this
actually works with my Windows 11 computer. MS should document that and
make a statement since which Windows version this actually works. This
isn't a strong requirement but it would be nice to wait for IOCPs with
WFMO in some cases.
Bonita Montero <Bonita.Montero@gmail.com>: Nov 24 08:59AM +0100

Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
 
>> ported to Windows from some other platform.
 
> Fwiw, check this out:
> https://sourceware.org/pthreads-win32/
 
Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
 
That's an unnecessary discussion for a C++ programmer since the RAII-ish
mutexes and condition variables since C++11 are more convenient to use.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 24 01:17AM -0800

On 11/23/2023 11:59 PM, Bonita Montero wrote:
 
> That's an unnecessary discussion for a C++ programmer since the RAII-ish
> mutexes and condition variables since C++11 are more convenient to use.
 
Have you ever wrapped up a C API in C++ using RAII before?
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 24 01:22AM -0800

On 11/23/2023 11:56 PM, Bonita Montero wrote:
> make a statement since which Windows version this actually works. This
> isn't a strong requirement but it would be nice to wait for IOCPs with
> WFMO in some cases.
 
Humm... You should be using:
 
https://learn.microsoft.com/en-us/windows/win32/fileio/getqueuedcompletionstatusex-func
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at No comments:

Tuesday, November 21, 2023

Digest for comp.lang.c++@googlegroups.com - 11 updates in 2 topics

gazelle@shell.xmission.com (Kenny McCormack): Nov 21 09:30AM

In article <ujfjn2$ae10$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
...
>for Windows and Linux (and I guess also for Macs). They are not
>particularly difficult to install or use, and no one needs to use an OS
>that they don't want to use.
 
I think you misunderstood his point. The point is that it is too easy
(currently) to automate the process of signing up with Google. This makes
it easy to mass-spam the newsgroups.
 
The whole point of his post is that we want it to be more difficult to
automate the process of signing up with Google. But there is a limit as to
how far to go on this road, since at some point (if you keep making it
harder and harder to sign up for Google), it becomes easier (for the
spammer/automater) to use some other newsreader (such as tin).
 
Got it now?
 
>The spammers are amateurs. Any professional spammer group would know
>perfectly well that flooding technical Usenet groups with Thai casino
>adverts is useless.
 
As another poster has suggested, I think something more nefarious is going
on. We should not assume that this is just another instance of the usual
"some poor schmuck in some god-forsaken third world shithole trying
desperately to make a few bucks so that they don't have to spend their
lives in grinding poverty" case.
 
In fact, I think Google is somehow in on it - i.e., from their POV, this
mess is a feature, not a bug. I make no assertion as to the details of
this, and I don't think we do ourselves any favors speculating about it.
 
>> the surreptitious control of bad actors.
 
>I don't blame /everything/ on Google - but this one is most certainly
>their fault.
 
Just to be clear, my underlying suggestion that I want Google to ban (i.e.,
make read-only) all the newsgroups is obviously a "not optimal, but perhaps
practical" sort of solution. They either can't or won't actually fix the
problem, so getting them out of the mess is the best we can hope for.
 
By the way, actually when you think about it, the idea of Google making
newsgroups read-only might actually be a good long-term solution. That
would allow newcomers (which as the other poster notes, we need to have a
steady stream of) to sample the wares w/o being able to post. They would
be encouraged to look around, decide they like it, then be instructed on
how to get setup with a real newsreader and news server. Works for
everybody!
 
--
"Remember when teachers, public employees, Planned Parenthood, NPR and PBS
crashed the stock market, wiped out half of our 401Ks, took trillions in
TARP money, spilled oil in the Gulf of Mexico, gave themselves billions in
bonuses, and paid no taxes? Yeah, me neither."
David Brown <david.brown@hesbynett.no>: Nov 21 04:47PM +0100

On 21/11/2023 10:30, Kenny McCormack wrote:
>> particularly difficult to install or use, and no one needs to use an OS
>> that they don't want to use.
 
> I think you misunderstood his point.
 
Perhaps.
 
> The point is that it is too easy
> (currently) to automate the process of signing up with Google. This makes
> it easy to mass-spam the newsgroups.
 
Yes, that's what I wrote.
 
> harder and harder to sign up for Google), it becomes easier (for the
> spammer/automater) to use some other newsreader (such as tin).
 
> Got it now?
 
It is already extremely easy to use a newsreader (other than tin). But
it typically involves a few google searches to find a free server :-)
 
Fair enough, however - I now see the point of Mike's post.
 
I don't think Google really see GG as a major part of their services.
They probably like having the Usenet archives, because they like all
sorts of information, but they certainly don't put much effort into
caring for the GG interface. It would take very little to make it much
more attractive to Usenet regulars, if they were interested in competing
for users.
 
> "some poor schmuck in some god-forsaken third world shithole trying
> desperately to make a few bucks so that they don't have to spend their
> lives in grinding poverty" case.
 
I am assuming incompetence or accident until I have reason to believe
there is a cunning conspiracy here. I am not ruling out something
intentional and evil, but I haven't yet seen convincing evidence. (I'm
also not sure it really matters very much - it makes no difference to
how annoying it is, or how little we can do about it.)
 
> make read-only) all the newsgroups is obviously a "not optimal, but perhaps
> practical" sort of solution. They either can't or won't actually fix the
> problem, so getting them out of the mess is the best we can hope for.
 
Agreed.
 
> be encouraged to look around, decide they like it, then be instructed on
> how to get setup with a real newsreader and news server. Works for
> everybody!
 
Even better would be to combine this with a decent web interface to
Usenet from someone other than Google (since Google can't seem to do it
properly). While many people (including me) find real newsreaders much
better than any web interface would be, there are still legitimate uses
for some people to use web interfaces.
gazelle@shell.xmission.com (Kenny McCormack): Nov 21 04:40PM

In article <ujijeg$sq9h$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
...
>properly). While many people (including me) find real newsreaders much
>better than any web interface would be, there are still legitimate uses
>for some people to use web interfaces.
 
Just out of curiosity, is there any advantage to a "web interface" (e.g.,
GG) vs a GUI (Windows/Mac/whatever) newsreader (Thunderbird, Claws, Forte,
etc) ? Isn't it pretty much the same thing?
 
(Of course, I understand the difference "under the hood", but I'm talking
here about what the typical naive user sees and understands)
 
--
"Everything Roy (aka, AU8YOG) touches turns to crap."
--citizens of alt.obituaries--
Richard Damon <richard@damon-family.org>: Nov 21 11:49AM -0500

On 11/21/23 11:40 AM, Kenny McCormack wrote:
> etc) ? Isn't it pretty much the same thing?
 
> (Of course, I understand the difference "under the hood", but I'm talking
> here about what the typical naive user sees and understands)
 
One advantage is it doesn't need to be "installed" or "updated" since it
doesn't actually live on the users computers.
 
It also automatically get shared with all your "devices", even if they
are using different operating systems. The programs you listed won't
work on a Phone or Tablet (at least not any of the popular ones), so
wouldn't be usable by a person who is largely "mobile".
scott@slp53.sl.home (Scott Lurndal): Nov 21 04:49PM


>Just out of curiosity, is there any advantage to a "web interface" (e.g.,
>GG) vs a GUI (Windows/Mac/whatever) newsreader (Thunderbird, Claws, Forte,
>etc) ? Isn't it pretty much the same thing?
 
Yes. A web interface can be often used when the outbound NNTP port is
blocked, for instance.
Michael S <already5chosen@yahoo.com>: Nov 21 10:03PM +0200

On Tue, 21 Nov 2023 11:49:02 -0500
> they are using different operating systems. The programs you listed
> won't work on a Phone or Tablet (at least not any of the popular
> ones), so wouldn't be usable by a person who is largely "mobile".
 
More so, "device" or computer does not even have to be yours.
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Nov 21 12:09PM -0800

David Brown <david.brown@hesbynett.no> writes:
[...]
> effort into caring for the GG interface. It would take very little
> to make it much more attractive to Usenet regulars, if they were
> interested in competing for users.
[...]
 
For example, Google could set up an NNTP server. But it's hard to
see how that would make money for them, and Google is not a charity.
(Possibly they could insert unobtrusive ads into the NNTP feed, but
the audience likely isn't big enough for that to be worthwhile.)
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
Michael S <already5chosen@yahoo.com>: Nov 21 10:16PM +0200

> it properly). While many people (including me) find real newsreaders
> much better than any web interface would be, there are still
> legitimate uses for some people to use web interfaces.
 
That's what https://www.novabbs.com/devel/ is.
Not the whole usenet, not even a major part of it, but most groups that
I am interested in are there.
By chance comp.editors that was mentioned in original post of this topic
is not there.
I am afraid that sooner rather than later spammers will find this
particular portal. I don't think that they will be able to spam through
it, but in attempts to do it they could easily degrade the quality of
service.
Michael S <already5chosen@yahoo.com>: Nov 21 10:23PM +0200

On Tue, 21 Nov 2023 16:49:34 GMT
> >Claws, Forte, etc) ? Isn't it pretty much the same thing?
 
> Yes. A web interface can be often used when the outbound NNTP port
> is blocked, for instance.
 
eternal-september.org can serve via HTTP port.
Lynn McGuire <lynnmcguire5@gmail.com>: Nov 21 02:42PM -0600

On 11/19/2023 5:23 AM, Kenny McCormack wrote:
> minute, 24/7.
 
> So, the question becomes, is there any way we can get Google to ban all
> newsgroups, not just these 2?
 
Ray Banana (E-S admin) blocked a back door that somebody had installed
this morning that GG spam was coming through. He may have gotten the
rest of it. The spammers will be looking for more back doors though.
 
Lynn
Bonita Montero <Bonita.Montero@gmail.com>: Nov 21 10:25AM +0100

Am 20.11.2023 um 21:18 schrieb Chris M. Thomasson:
 
> Did you read that article on MSDN as well? Iirc, its around 20 years old.
 
Has WFMO ever changed ?
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at No comments:

Monday, November 20, 2023

Digest for comp.lang.c++@googlegroups.com - 10 updates in 2 topics

Bonita Montero <Bonita.Montero@gmail.com>: Nov 20 01:26PM +0100

Am 19.11.2023 um 21:08 schrieb Chris M. Thomasson:
 
> I suspect that you are unfamiliar with how WaitForMultipleObjects
> works... ...
 
Absolutely not, but with WFMO you'd need a lot of semaphores or events
whereas my solution needs one semaphore and you'd be limited to MAXIMUM
_WAIT_OBJECTS == 64 threads which can join the barrier.
And why do you think I didn't know that ? I've shown that I used that
with my monitor and you even didn't have to look at the source since
I've explained that I'm using WFMO multiple times.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 20 12:18PM -0800

On 11/20/2023 4:26 AM, Bonita Montero wrote:
> And why do you think I didn't know that ? I've shown that I used that
> with my monitor and you even didn't have to look at the source since
> I've explained that I'm using WFMO multiple times.
 
I was just thinking about the case that did not have to wait on all the
events your are passing into WFMO to be in a signaled state. That old
50,000 connection test (event vs. iocp) required us to shift their
positions in the array in order to get around some starvation issues...
 
Did you read that article on MSDN as well? Iirc, its around 20 years old.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 20 01:12PM -0800

On 11/18/2023 5:20 PM, Pavel wrote:
> NP, Scott is correct, this was about "wait for many conditions to be met
> at once" that Bonita missed on Linux for some reason I still cannot get
> or relate to.
 
It guess Bonita does not know that a predicate for a condition variable
can contain many conditions.
Japanese Spammer Here <invalid@invalid.net>: Nov 19 11:25PM

On 19/11/2023 11:23, Kenny McCormack wrote:
> So, the question becomes, is there any way we can get Google to ban all
> newsgroups, not just these 2?
 
Yes just keep posting more spam using google Groups and they will ban as
soon as they come to know of them. Now you can't buy your drugs anymore! Shame on you.
doctor@doctor.nl2k.ab.ca (The Doctor): Nov 20 12:04AM

In article <uje5qp$qb8g$1@paganini.bofh.team>,
 
>Yes just keep posting more spam using google Groups and they will ban as
>soon as they come to know of them. Now you can't buy your drugs anymore!
>Shame on you.
 
LOL!
Still GG is banned on this node!
--
Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism ; unsubscribe from Google Groups to be seen
Merry Christmas 2023 and Happy New year 2024 Beware https://mindspring.com
David Brown <david.brown@hesbynett.no>: Nov 20 08:42AM +0100

On 19/11/2023 18:18, Mike Terry wrote:
> hassle; once it's circulating around the system it's an order of
> magnitude more effort to deal with. [Yeah, I get that Usenet SPAM is not
> Google's priority!]
 
I agree with you here. Although most of the regulars in these technical
groups use proper Usenet clients, there are some who - for good or bad
reasons - use GG. And it is undoubtedly the main source of new members
for most groups.
 
Really, it is absurd that Google are not fixing this issue, because it
is not just a GG/Usenet matter. They need to make it more
time-consuming to open a new google account, involve more user
interaction, and put limits on the numbers of new accounts from the same
IP within a short time-frame. It is far too easy to automate the
creation of new gmail address accounts, and that is a big source of
spam, malware and other problems for all of google. If they stop the
bots getting the new accounts, then a simple decades-old Bayesian filter
is enough to identify these spam posts and close the account.
 
They could also easily have limits on Usenet postings from new accounts.
No posts for the first 20 minutes, then max 3 posts in the first 24
hours. Combine that with delays, limits and checks on new accounts, and
the problem would be solved without bothering existing users.
Kaz Kylheku <864-117-4973@kylheku.com>: Nov 20 07:56AM

> is not just a GG/Usenet matter. They need to make it more
> time-consuming to open a new google account, involve more user
> interaction,
 
Just not so demanding of time and interaction that it becomes easier to
set up Linux and run tin
 
Just not that it's easier to install Linux and run tin.
 
> and put limits on the numbers of new accounts from the same
> IP within a short time-frame.
 
"Same IP" only works against the pure amateurs who do not harness large
numbers of different IP addresses by using botnets or their own IP
blocks.
 
Before we blame everything on Google, the first step is getting
Microsoft to fix the problem that millions of Windows machines are under
the surreptitious control of bad actors.
 
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
David Brown <david.brown@hesbynett.no>: Nov 20 01:33PM +0100

On 20/11/2023 08:56, Kaz Kylheku wrote:
 
> Just not so demanding of time and interaction that it becomes easier to
> set up Linux and run tin
 
> Just not that it's easier to install Linux and run tin.
 
Why would anyone choose to run tin, unless they have been using it for
the last three decades? There are many free Usenet clients available,
for Windows and Linux (and I guess also for Macs). They are not
particularly difficult to install or use, and no one needs to use an OS
that they don't want to use.
 
Pretty much any human who wants to use GG to access Usenet will already
have a google account - extra hurdles on making new google accounts
won't affect them. For the tiny proportion that need to make a new
account, it should not be an issue if they have an extra step or two of
captchas, SMS codes, or whatever.
 
 
> "Same IP" only works against the pure amateurs who do not harness large
> numbers of different IP addresses by using botnets or their own IP
> blocks.
 
The spammers are amateurs. Any professional spammer group would know
perfectly well that flooding technical Usenet groups with Thai casino
adverts is useless.
 
> Before we blame everything on Google, the first step is getting
> Microsoft to fix the problem that millions of Windows machines are under
> the surreptitious control of bad actors.
 
I don't blame /everything/ on Google - but this one is most certainly
their fault.
Mike Terry <news.dead.person.stones@darjeeling.plus.com>: Nov 20 06:06PM

On 20/11/2023 12:33, David Brown wrote:
>> blocks.
 
> The spammers are amateurs.  Any professional spammer group would know perfectly well that flooding
> technical Usenet groups with Thai casino adverts is useless.
 
So what do you believe is "the point" of all the current spam?
 
That's a serious question - if you believe it is hoping that someone reads a particular spam post
and sees some online betting web site link and thinks "aha, I was just thinking about doing some
online gambling, and as luck has it I've just come across a link. I might as well use that one!"
then indeed the spammers would be worse than amateurs - they'd be idiots, and nobody would pay them
for that! :)
 
So I'll suggest another reason: the intent of the spam is to pervert the Google search weighting
algorithms in an attempt to move particular sites up the rankings, aiming at an ideal outcome of
appearing on the first page of a search. Individuals have been claiming to be able to do this for
almost as long as search engines like Google have become financially important to buisnesses, and it
seems 100% plausible to me that it can be done - of course you would need to have a good
understanding of how Google rankings work [which I don't!], but then you exploit that knowledge to
"trick" Google into thinking particular sites are more popular than they really are. Probably it
would involve injecting document for Google to scan (Usenet articles?) containing lots of mentions
of the keywords of interest in association with links of interest. It wouldn't be particularly
relevant what human readers made of those documents.
 
So an indicator of this going on might be articles consisting primarily of long lists of links to
promoted websites. Like you say, who is going to actually read and absorb such a "silly" list of
links? Perhaps Google ranking algorithms? (I don't know, but that's all I can think of - anyhow,
such lists of links is exactly what 99% of the spam consists of...)
 
Seems we're on the same page regarding Google needing to fix their account creation process so it is
more expensive in human manpower. While there is no cost using some automated process, banning
users for spamming achieves very little. I can see that Google fixing this isn't going to be
instant, but there's also the route of simply identifying spam on prima facae grounds and blocking
it at entry. Google don't seem to like that approach for some reason. Perhaps they see it as just
escalating the spam war requiring constant investment to keep up with spammers, and Google want a
zero on-going effort (on their part) solution.
 
 
Regards,
Mike.
 
 
 
David Brown <david.brown@hesbynett.no>: Nov 20 09:01PM +0100

On 20/11/2023 19:06, Mike Terry wrote:
>> perfectly well that flooding technical Usenet groups with Thai casino
>> adverts is useless.
 
> So what do you believe is "the point" of all the current spam?
 
I really don't know.
 
> the Google search weighting algorithms in an attempt to move particular
> sites up the rankings, aiming at an ideal outcome of appearing on the
> first page of a search.
 
That would have made sense with the page ranking algorithms from the
early days of search engines, but not now - mass spamming of links and
adverts does not boost your ratings on google. But you could be on to
something here - perhaps the spammers don't understand the page ranking
systems and /think/ that it will boost them, or perhaps it still works
on some less sophisticated search engines (there are many used around
the world - google is not dominant everywhere).
 
> this for almost as long as search engines like Google have become
> financially important to buisnesses, and it seems 100% plausible to me
> that it can be done
 
Nah - there is no need to be able to provide any results in order to
/claim/ you can boost rankings. The ones that actually work are simply
buying sponsored phrases at google, and charging people more than google
charges them.
 
> Google ranking algorithms?  (I don't know, but that's all I can think of
> - anyhow, such lists of links is exactly what 99% of the spam consists
> of...)
 
I don't think that would actually work at all, but I can't be sure (I am
not privy to the details of google's algorithms). And certainly if the
spammers believe this would work (whether or not it /actually/ works),
it would be a rational reason for targetting Usenet groups. However, I
am still inclined to suspect that this is all either a mistake, an
unintentional side-effect (with Usenet posts instead of email posts), or
a spamming subcontracter scamming a spamming customer.
 
> to like that approach for some reason.  Perhaps they see it as just
> escalating the spam war requiring constant investment to keep up with
> spammers, and Google want a zero on-going effort (on their part) solution.
 
Maybe google gets advertising revenue from the websites, and so doesn't
mind the spam?
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at No comments:

Sunday, November 19, 2023

Digest for comp.lang.c++@googlegroups.com - 16 updates in 3 topics

gazelle@shell.xmission.com (Kenny McCormack): Nov 19 11:23AM

The good news: The spam problem (both the so-called "Thai spam" and the
"mushroom spam") is gone from clc and clc++, because Google has (for
reasons of its own) banned both groups. What's funny about this is that
normally people on these groups would be p*ssed off at Google for banning
them, but in this instance, it is a happy coincidence that it stops the
spam. So, we're good with it.
 
The bad news is that it is still alive and well in many of the other
groups. Right now, comp.editors is getting slammed - about 1 spam per
minute, 24/7.
 
So, the question becomes, is there any way we can get Google to ban all
newsgroups, not just these 2?
 
--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/FreeCollege
Mike Terry <news.dead.person.stones@darjeeling.plus.com>: Nov 19 05:18PM

On 19/11/2023 11:23, Kenny McCormack wrote:
> minute, 24/7.
 
> So, the question becomes, is there any way we can get Google to ban all
> newsgroups, not just these 2?
 
I don't see disconnection from GG as a Good Thing in the long term. Many groups have the core of
their followers using GG, and how many will be persuaded to migrate to Usenet? But the real problem
as I see it is for long term survival groups need a stream of NEW users, and I'd guess close to 100%
of those come via GG, and hopefully they're persuaded later by regulars of the advantages of Usenet.
 
When I started using the internet my ISP provided the connection obviously, and a document
explaining how to configure my computer to connect to their email and USENET servers. So email,
Usenet, and WWW were the 3 motivations for "getting the internet", and newsgroups were the place you
went for general discussion. Those days are long gone, and whilst my current ISP still has a Usenet
service (subcontracted to Giganews) there's absolutely no mention of it in their advertising, legal
contracts, etc. and you have to hunt hard, knowing what you're looking for, to find any help pages
for it. So no new internet users are going to think "Right, now how do I get a Usenet client, and
where's my Usenet server?!" If they eventually find Usenet it will likely be via GG.
 
Disconnection from GG will cut off the supply of new users - a kind of "kiss of death" for the long
term health of the group. Groups with an essentially static membership could obviously continue as
they are for years, dieing slowly as their members age and finally depart the group. It's like
these groups are slowly dieing anyway, so another nail in the coffin for long-term Usenet health is
hardly a problem - they want the SPAM gone NOW...
 
It would be better long term if Google could apply some better SPAM filtering technology, perhaps
leveraging all their clever AI technology?, to block the spam entering the system in the first
place. It's at the point of initial entry that SPAM can be handled with minimum hassle; once it's
circulating around the system it's an order of magnitude more effort to deal with. [Yeah, I get that
Usenet SPAM is not Google's priority!]
 
 
Mike.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 19 11:51AM -0800

On 11/19/2023 9:18 AM, Mike Terry wrote:
 
> It would be better long term if Google could apply some better SPAM
> filtering technology, perhaps leveraging all their clever AI
> technology?, to block the spam entering the system in the first place.
[...]
 
I wonder if somebody writes this method A simply trumps method B. The AI
says ahhh shit, trump, and blocks the message? lol.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 19 12:25PM -0800

On 11/19/2023 3:23 AM, Kenny McCormack wrote:
> The good news: The spam problem (both the so-called "Thai spam" and the
> "mushroom spam") is gone from clc and clc++, because Google has (for
> reasons of its own) banned both groups.
 
Afaict, they made them read only. In the past, they actually tried to
ban them wrt reads and writes. Damn it.
 
 
 
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Nov 18 08:09PM -0500

Scott Lurndal wrote:
 
>> Again, what a system call that waits for many conditions to be met at
>> once can be useful for?
 
> Rendezvous.
Is it even useful? I got familiar with it first in late 80s while
learning Ada but never needed it since, even as a concept.
> e.g. pthread_barrier_wait.
 
It seems to work well as it is, my feeling is that implementing it in
user space on top of some "wait_for_all_xxxs" (which is on itself too
high-level for my taste) would not be efficient.
 
After giving it some thought, I think I could write a reasonable
implementation with 1 mutex, 1 condvar and 2 ints (unless some
"predictable scheduling policy" is required -- but the implementation
with "wait_for_all_xxxs" should have issue with it as well).
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Nov 18 08:18PM -0500

Kaz Kylheku wrote:
 
> Also this:
 
> while (!this_condition() && !that_condition() && !other_condition())
> pthread_cond_wait(&cond, &mutex);
 
I had to solve similar tasks once in a while, would usually just have a
count of conditions left or a mask of condition wanted as bits and the
thread satisfying a condition would only signal once count is zero or
the mask covers all conditions, respectively to
- avoid unnecessary wake-ups;
- let waiters check that count or mask instead of doing multiple checks
 
 
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Nov 18 08:20PM -0500

Chris M. Thomasson wrote:
 
>> I took Pavel to mean 'wait for all conditions to be true' rather than
>> 'wait for one or more conditions to be true'.
 
> Ahhh. I missed that. Sorry everybody! ;^o
NP, Scott is correct, this was about "wait for many conditions to be met
at once" that Bonita missed on Linux for some reason I still cannot get
or relate to.
Bonita Montero <Bonita.Montero@gmail.com>: Nov 19 05:58AM +0100

Am 18.11.2023 um 20:24 schrieb Scott Lurndal:
 
> e.g. pthread_barrier_wait.
 
pthread_barrier_wait is for multiple threads joining on one event,
not one thread waiting for multiple events as discussed.
Kaz Kylheku <864-117-4973@kylheku.com>: Nov 19 05:02AM


>> e.g. pthread_barrier_wait.
 
> pthread_barrier_wait is for multiple threads joining on one event,
> not one thread waiting for multiple events as discussed.
 
That is untrue; there are effectively N events in a barrier:
 
- thread 1 has arrived at the barrier
- thread 2 has arrived at the barrier
...
- thread N has arrived at the barrier
 
When all these events have occurred, then all threads at the barrier are
released (and an indication is given to one of them that it is the
special "serial thread").
 
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
Bonita Montero <Bonita.Montero@gmail.com>: Nov 19 07:00AM +0100

Am 19.11.2023 um 06:02 schrieb Kaz Kylheku:
 
>> pthread_barrier_wait is for multiple threads joining on one event,
>> not one thread waiting for multiple events as discussed.
 
> That is untrue; there are effectively N events in a barrier:
 
No, a barrier internally consists of an atomic which each thread
decrements and if it wasn't the last thread decrementing the atomic
it waits for a semaphore, a.k.a. event, which is signalled by the
last thread which decremented the atomic.
Kaz Kylheku <864-117-4973@kylheku.com>: Nov 19 06:08AM


>> That is untrue; there are effectively N events in a barrier:
 
> No, a barrier internally consists of an atomic which each thread
> decrements
 
That's an implementation detail. Because the events are one-shots we can
just use a counter to represent the state that we need for the barrier
to be able to conclude that all events have occurred.
 
Each "thread P is waiting for barrier" event is a one shot, because
once a thread is waiting, that fact stays latched.
 
If the waiting threads could get nervous and leave the barrier
before it activates, then a counter could not be used; there would
have to be a set representation like a bitmask.
 
Rest unread.
 
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
Bonita Montero <Bonita.Montero@gmail.com>: Nov 19 12:05PM +0100

Am 19.11.2023 um 07:08 schrieb Kaz Kylheku:
 
> That's an implementation detail. ...
 
That's how it works.
So from the scheduling / kernel perspective there's only one event.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 19 12:08PM -0800

On 11/19/2023 3:05 AM, Bonita Montero wrote:
 
>> That's an implementation detail. ...
 
> That's how it works.
> So from the scheduling / kernel perspective there's only one event.
 
I suspect that you are unfamiliar with how WaitForMultipleObjects
works... I remember a test for 50,000 concurrent connections, that was
mentioned by Microsoft. It was testing events vs IOCP. Did you know that
they recommended altering the indexes of the events waited for by
WaitForMultipleObjects? I remember it, is was a long time ago, 2001 ish,
iirc.
 
Iirc, it was recommended to basically randomize, or shift the indexes.
God damn, I need to find that old post on msdn. Again, iirc, if we did
not do this, some events could starve in the server experiment.
 
The funny part is that the event based model performed pretty good, not
as scalable as IOCP, however, IOCP did not completely blow it out of the
water wrt performance and throughput.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 19 12:11PM -0800

On 11/19/2023 12:08 PM, Chris M. Thomasson wrote:
 
> The funny part is that the event based model performed pretty good, not
> as scalable as IOCP, however, IOCP did not completely blow it out of the
> water wrt performance and throughput.
 
After I read that msdn post, I basically created a proxy server. One
using events, and another using IOCP. IOCP beats it, but did not
slaughter it at that time. I found that to be interesting.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 19 12:17PM -0800

On 11/19/2023 12:11 PM, Chris M. Thomasson wrote:
 
> After I read that msdn post, I basically created a proxy server. One
> using events, and another using IOCP. IOCP beats it, but did not
> slaughter it at that time. I found that to be interesting.
 
That's way back when I remember using AIO for the HTTP proxy server over
on Linux and compared it to IOCP. Time flies!
Bonita Montero <Bonita.Montero@gmail.com>: Nov 19 12:04PM +0100

I was interested in whether my C++ implementations pass the lambda you
supply with std::sort through the recursion of sort by coping. libstdc++
(g++) and libc++ (clang++) copy the lambda at each recursion level. MSVC
stores the lambda only once.
 
#include <iostream>
#include <vector>
#include <random>
#include <unordered_map>
#include <climits>
#include <algorithm>
 
using namespace std;
 
int main( int argc, char **argv )
{
mt19937_64 mt;
uniform_int_distribution<int> uid( INT_MAX, INT_MAX );
vector<int> vi;
vi.reserve( 1'000 );
for( size_t i = vi.capacity(); i--; )
vi.emplace_back( uid( mt ) );
unordered_map<void const *, size_t> addresses;
bool invert = argc > 1;
sort( vi.begin(), vi.end(),
[&, invert = invert]( int lhs, int rhs )
{
++addresses[&invert];
if( !invert )
return lhs < rhs;
else
return rhs < lhs;
} );
for( auto &pCount : addresses )
cout << pCount.first << ": " << pCount.second << endl;
}
 
I think for std::sort it would be the best to store the complete
state the lambda refers to as a static or thread_local variable
that the lambda itself doesn't need any state to be copied that
there's actually no parameter passed through the recursion.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at No comments:

Thursday, November 16, 2023

Digest for comp.lang.c++@googlegroups.com - 14 updates in 1 topic

Bonita Montero <Bonita.Montero@gmail.com>: Nov 16 03:59AM +0100

Am 15.11.2023 um 21:08 schrieb Chris M. Thomasson:
 
> Are you sure its 100% atomic for use in multi-thread sync algorithms?
 
If MSVC generates that code it's atomic.
Bonita Montero <Bonita.Montero@gmail.com>: Nov 16 04:00AM +0100

Am 15.11.2023 um 21:21 schrieb Chris M. Thomasson:
 
> Correction? Just post the 100% finished code in a brand new thread.
 
I've postet everything that is necessary, you only have to add a "!".
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 15 07:10PM -0800

On 11/15/2023 7:00 PM, Bonita Montero wrote:
> Am 15.11.2023 um 21:21 schrieb Chris M. Thomasson:
 
>> Correction? Just post the 100% finished code in a brand new thread.
 
> I've postet everything that is necessary, you only have to add a "!".
 
Wow... Anyway, where do I add this "!"?
Kaz Kylheku <864-117-4973@kylheku.com>: Nov 16 03:21AM


>>> Correction? Just post the 100% finished code in a brand new thread.
 
>> I've postet everything that is necessary, you only have to add a "!".
 
> Wow... Anyway, where do I add this "!"?
 
I would guess, in front of "necessary".
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Nov 15 11:07PM -0500

Chris M. Thomasson wrote:
>> according to the spec.
 
> Just as long as the implementation works wrt calling
> pthread_cond_signal/broadcast outside of the mutex. If not, it is broken.
 
I am unsure where from that discussion of implementation came. The
*spec* permits this (signalling without holding the mutex), just warns
that a predictable scheduling behavior cannot be achieved then.
 
What would you consider an example of a "non-working" implementation?
 
Does my example that illustrates how a higher-prio thread may never make
progress is of a broken implementation in your opinion?
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Nov 16 12:25AM -0500

Kaz Kylheku wrote:
> concrete requirements about what it is that I'm supposed to do in
> pthread_cond_signal to bring about more predictable scheduling.
 
> Specifications should give specific requirements, not vague opinions.
 
POSIX *specifies* exactly what scheduling policies a compliant
implementation shall support (SCHED_OTHER, SCHED_FIFO, SCHED_RR, and
SCHED_SPORADIC) and how exactly each of these shall behave.
 
In addition to specifying the behavior, the spec *explains* the purpose
of some policies so programmers would know when they were meant to be
used. Explanations are there to be helpful, they are not specs. In C++
Standard, they would be formatted as a non-normative Notes.
 
For example, SCHED_RR, under some conditions, has an effect "to ensure..
that one of them [the threads] does not monopolize the processor". To
me, this is clearly an example of "predictable scheduling behavior".
 
The spec for pthread_cond_signal and broadast further simply adds one
more condition required to achieve such behavior, namely "the signalling
thread owns the mutex that the waiter threads used to start waiting". If
your doesn't need a predictable scheduling behavior, your app doesn't
have to do that.
 
For an implementer, this statement is actually very useful: it permits
them to not ensure "predictable scheduling behavior" when the cond
waiter is signaled from a thread not owning the mutex.
 
Could this statement be thrown away? -- Yes. Would this make
implementor's life easier? -- No, it would make it much harder. The
implementor could be bugged by the user complaints like "Your
implementation must be broken, else why my higher-prio thread is
starving?". With the current spec, they could answer: "This is because
the spec allows my implementation to starve your higher-prio thread to
death -- or exhibit any other unpredictable scheduling behavior -- if
your condvar-signalling thread does not own the mutex that the
higher-prio thread used to start waiting for the condvar".
Bonita Montero <Bonita.Montero@gmail.com>: Nov 16 06:36AM +0100

Am 16.11.2023 um 04:10 schrieb Chris M. Thomasson:
 
> Wow... Anyway, where do I add this "!"?
 
You don't have to change it because the Windows code was correct
anyway.
Kaz Kylheku <864-117-4973@kylheku.com>: Nov 16 06:39AM

> I am unsure where from that discussion of implementation came. The
> *spec* permits this (signalling without holding the mutex), just warns
> that a predictable scheduling behavior cannot be achieved then.
 
The spec is supposed to tell implementors what to make.
 
Loose wording like this is dangerous. An implementor is free to
interpret it like this: whenever a program calls pthread_cond_signal,
and it so happens that the calling threads owns no mutex whatsoever, the
implementation is free to set a flag somewhere, based on which it will
willfully damage the integrity of the scheduling implementation somehow,
so that it behaves like crap.
 
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
Bonita Montero <Bonita.Montero@gmail.com>: Nov 16 11:11AM +0100

Am 13.11.2023 um 05:50 schrieb Kaz Kylheku:
 
> is still holding. So, oops, back it goes into suspended state, and
> we have to context switch to the mutex holder which has to release
> the mutex and then switch to that signaled thread again.
 
As I've shown with the comparison of my monitor against a C++ mutex
along with a condition variable there are no additional context swit-
ches with that. The number of voluntary context switches is about the
same as with my monitor, which comprehensibly waits for the mutex and
the condition variable in one step.
As the mutex part and the condition variable part are separate there's
no opportunity to implement that the way I did with a SysV semaphore
set. I guess the backing of the mutex and condition variable on Linux
is the glibc-implementation and it uses signals for that as when you
use a pure mutex; with that you can have an aribitrary state combina-
tion to wake up a thread even if the states are managed separately as
with a mutex and a condition variable.
 
I simulated that with the follwing code:
 
 
#include <iostream>
#include <thread>
#include <vector>
#include <pthread.h>
#include <sys/resource.h>
 
using namespace std;
 
int main()
{
constexpr size_t ROUNDS = 1'000;
struct state
{
pthread_mutex_t mtx;
pthread_cond_t cv;
} a, b;
auto init = []( state &s )
{
if( pthread_mutex_init( &s.mtx, nullptr )
|| pthread_cond_init( &s.cv, nullptr ) )
terminate();
};
init( a );
init( b );
auto switches = []()
{
rusage ru;
if( getrusage( RUSAGE_THREAD, &ru ) )
terminate();
return ru.ru_nvcsw;
 
};
atomic_uint64_t sumSwitches( 0 );
auto thr = [&]( state &my, state &yours )
{
uint64_t before = switches();
for( size_t r = ROUNDS; r--; )
if( pthread_mutex_lock( &my.mtx )
|| pthread_cond_wait( &my.cv, &my.mtx )
|| pthread_mutex_unlock( &my.mtx )
|| pthread_mutex_lock( &yours.mtx )
|| pthread_cond_signal( &yours.cv )
|| pthread_mutex_unlock( &yours.mtx ) )
terminate();
sumSwitches.fetch_add( switches() - before, memory_order_relaxed );
};
vector<jthread> threads;
threads.emplace_back( thr, ref( a ), ref( b ) );
threads.emplace_back( thr, ref( b ), ref( a ) );
if( pthread_cond_signal( &a.cv ) )
terminate();
threads.resize( 0 );
cout << sumSwitches << endl;
}
 
The result is about 2'000 voluntary context switches.
So no need to signal from outside.
scott@slp53.sl.home (Scott Lurndal): Nov 16 03:02PM

>Am 15.11.2023 um 21:08 schrieb Chris M. Thomasson:
 
>> Are you sure its 100% atomic for use in multi-thread sync algorithms?
 
>If MSVC generates that code it's atomic.
 
No, if Intel architecture documentation specifies that it is
single-copy atomic, then it is single-copy atomic.
 
MSVC is just a poor-to-middling C compiler.
Bonita Montero <Bonita.Montero@gmail.com>: Nov 16 06:12PM +0100

Am 16.11.2023 um 16:02 schrieb Scott Lurndal:
 
>> If MSVC generates that code it's atomic.
 
> No, if Intel architecture documentation specifies that it is
> single-copy atomic, then it is single-copy atomic.
 
MSVC relies for sure on the right behaviour.
 
> MSVC is just a poor-to-middling C compiler.
 
MSVC has the strongest C++20-conformance but the weakest optimizer.
scott@slp53.sl.home (Scott Lurndal): Nov 16 05:45PM


>> No, if Intel architecture documentation specifies that it is
>> single-copy atomic, then it is single-copy atomic.
 
>MSVC relies for sure on the right behaviour.
 
Right. Keep thinking that.
 
 
>> MSVC is just a poor-to-middling C compiler.
 
>MSVC has the strongest C++20-conformance but the weakest optimizer.
 
Faint praise, indeed. Nobody other than Herb cares about C++20 conformance.
 
Most real world C++ code relies on C++11 for portability. Most
of our systems and our customers systems don't even support C++17.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 16 01:06PM -0800

On 11/15/2023 9:36 PM, Bonita Montero wrote:
 
>> Wow... Anyway, where do I add this "!"?
 
> You don't have to change it because the Windows code was correct
> anyway.
 
Huh? Do I have to correct your code with that "!" or not?
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 16 02:16PM -0800

On 11/12/2023 4:44 PM, Chris M. Thomasson wrote:
> signalling thread, instant contention. However, wait morphing techniques
> can be used to handle this since a mutex and a condvar are very intimate
> with each other anyway. Usually, signalling outside of the mutex is ideal.
 
Actually, for some damn reason this is making me think about the
pass-the-buck algorithm, iirc, its from SUN.
 
A signal to a thread means the signaled thread already owns the mutex.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at No comments:
Subscribe to: Comments (Atom)