https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106772
--- Comment #24 from Mkkt Bkkt ---
(In reply to Thomas Rodgers from comment #22)
> Your example of '100+ core' systems especially on NUMA is certainly a valid
> one. I would ask, at what point do those collisions and the resulting cache
> invali
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106772
--- Comment #23 from Mkkt Bkkt ---
(In reply to Thomas Rodgers from comment #21)
> I wasn't sarcastic in what I posted. As I noted, this question has come up
> before in different contexts, Bugzilla is a useful historical archive, so
> updating
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106772
--- Comment #20 from Mkkt Bkkt ---
My main concern with this optimization it's not zero-overhead.
It's not necessary when we expect we have some waiters, in that case it just
additional synchronization and contention in waiter pool (that have s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106772
--- Comment #19 from Mkkt Bkkt ---
An example with a futex or other syscall would also work, because atomic::wait
is still not widely used.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106772
--- Comment #18 from Mkkt Bkkt ---
Thanks for provide source of your benchmarks!
Can you also provide some example of usage atomic::notify where this
optimization is needed?
If it exists I think you right and it is necessary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106772
--- Comment #16 from Mkkt Bkkt ---
> it with sarcasm
I started with sarcasm because you restart this thread with some doubtful
benchmarks without code for them.
I think it's very disrespectfully.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106772
--- Comment #15 from Mkkt Bkkt ---
> If you have an atomic counter and want to signal when it has been
> incremented, you cannot tell from the previous value whether another thread
> is waiting.
I wrote it example.
Do you talk about like se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106772
--- Comment #13 from Mkkt Bkkt ---
example of simple mutex pseudocode that don't need call notify every unlock:
Same possible for other cases, if it doesn't please share example for me
```
int kUnlocked = 0;
int kLocked = 1;
int kLockedWithWait
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106772
--- Comment #12 from Mkkt Bkkt ---
First of, I was a toxic, sorry.
But you start this first, maybe it's allowed for maintainer, I don't know.
But I still waiting code of benchmarks.
Also I want to see example of usage when we notify atomic, th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106772
--- Comment #9 from Mkkt Bkkt ---
Why do you think you smarter than msvc stl, libc++, boost::atomic developers?
Maybe it's about your "I"?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106772
--- Comment #8 from Mkkt Bkkt ---
> I have every confidence that Lewis knows how to bring a paper for a
> 'lightweight manual reset event' to SG1, I suspect it will be well received
> when he does.
So at least before C++26 I and any other dev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106772
--- Comment #7 from Mkkt Bkkt ---
Can you give example when this optimization needed and cannot be done on user,
not stdlib side?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106772
--- Comment #5 from Mkkt Bkkt ---
Single reason why I want to use atomic::wait/notify is cross platform api for
futex, wait/wake on address, ulock, etc
Not because I need YOU decide instead of me how many spins, or other
optimization I need.
bo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106772
--- Comment #4 from Mkkt Bkkt ---
Nice, thanks for benchmarks without code.
Also, why do I need call notify when don't have wait?
Common usage from my point of view looks like:
atomic.wait(value, mo):
while (atomic.load(mo) == value) {
fu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106772
--- Comment #1 from Mkkt Bkkt ---
libc++ implementation do it.
msvc stl of course too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106772
Bug ID: 106772
Summary: atomic::wait shouldn't touch waiter pool if used
platform wait
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137
--- Comment #51 from Mkkt Bkkt ---
(In reply to Avi Kivity from comment #50)
> Your reproducer does pass in trunk. So perhaps just a missing backport.
Yes, I forgot to mention that.
I hope you are right and someone will make these backports in 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137
Mkkt Bkkt changed:
What|Removed |Added
CC||valera.mironow at gmail dot com
--- Comment
18 matches
Mail list logo
