Sunday, May 17, 2020

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

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 12 02:23PM -0700

On 5/12/2020 2:14 PM, Bonita Montero wrote:
 
> I just think that if you add additional code, the timing of
> the spinning will change, that Öö Tiib could get into trouble
> to prove what he assumes.
 
Huh?
red floyd <no.spam.here@its.invalid>: May 12 11:15PM -0700

On 5/12/2020 11:14 PM, Bonita Montero wrote:
 
>> I had to add a destructor to the Semaphore class to close the handle.
 
> Also not necessary for the purpose of this code, that's while I skipped
> it.
 
So anyone who disagrees with you is stupid. Bye bye... *PLONK*
Bonita Montero <Bonita.Montero@gmail.com>: May 13 08:09AM +0200

> I should say that sem_wait returns -1 and errno can be EINTR.
 
That's experimental code. EINTR normally doesn't happen.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 12 11:21PM -0700

On 5/12/2020 11:20 PM, Bonita Montero wrote:
>> lol. Okay... Whatever. Anyway, your code works in a Relacy test unit. :^)
 
> Sorry, there's no need for Relacy here because the mutex is simple.
 
It found a memory leak and a dead lock condition wrt EINTR.
Bonita Montero <Bonita.Montero@gmail.com>: May 13 08:08AM +0200

> Fwiw, this is a bug. You are misusing sem_wait. ...
 
No.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 13 04:28PM -0700

On 5/13/2020 5:10 AM, Bonita Montero wrote:
> Compile the following like this:
> g++ -O3 -pthread SpinMutex.cpp spendCycles.s
[...]
 
I have not tried to compile it with g++ yet. I just ported it over to
Relacy simply because the porting process is a nice way to learn the
algorithm, and it helps flush out buggers. No matter how short it is.
 
The main point is that the lock logic itself works fine.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 13 03:36PM +0200

On 13.05.2020 08:29, Bonita Montero wrote:
 
> You're such a mega-idiot. That's not industrial-level code, it's
> expermental to allow to prove Öö Tiibs assumptions. And for this
> puprose it is completely adequate.
 
If it doesn't need to be correct it can be arbitrarily simple and fast.
 
- Alf
Bonita Montero <Bonita.Montero@gmail.com>: May 12 11:06PM +0200

> [...]
 
> Thank you! Okay, will bust out Relacy and port it.
> Sometime today, or tomorrow.
 
Sorry, that's like debugging hello world. Read the code and you'll
see in 10min that is correct (aside from non-handled resource-erors).
Bonita Montero <Bonita.Montero@gmail.com>: May 12 10:14PM +0200

>> My mutex exactly does the same what the Windows mutex does.
 
> You just tried to tell us that Windows has a fixed spin count. ;^o
 
You don't understand what I mean with "fixed spin-count". I don't mean
that it isn't adjustable after creation of the mutex. I mean that it
isn't adaptive like with Linux.
 
> Relacy can be found here:
> https://github.com/dvyukov/relacy
> Trust me, it helps.
 
I'm pretty sure you haven't read my code.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 12 01:49PM -0700

On 5/12/2020 1:41 PM, Chris M. Thomasson wrote:
 
>> The C-standard isn't defining what we're talking about here.
>> The Wikipedia should be more definitive.
 
> Huh? Wow.
 
Wrt Pelles C, check I found another issue:
 
https://forum.pellesc.de/index.php?topic=7167
Bonita Montero <Bonita.Montero@gmail.com>: May 12 04:14PM +0200

> How should anyone know if you wanted static or non-static members
> when you wrote static?
 
You said that the accessors need to be static so you alleged
to know it.
 
> usually contains serious logic errors too. About buggy software
> however no one cares how fast it behaves incorrectly and gives
> bogus answers. So test it yourself.
 
 
My code does everything what it is needed to prove what
you assume - if it can be proven. So give me the numbers !
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 12 01:36PM -0700

On 5/12/2020 1:35 PM, Bonita Montero wrote:
>> then understand your corrections?
 
> The code is short and simple and you even have the time to write
> a lot of nonsense-postings here.
 
Oh common. You are not paying me. Just create a brand new thread, and
post the most recent version so we can all get on the same page. Heck,
even post it to GitHub.
Bonita Montero <Bonita.Montero@gmail.com>: May 12 10:20PM +0200

>> _with_spin_lock_does_ and show wich are the appropriate parameters
>> which show the benefit of spinning !
 
> You said Windows uses a fixed spin count. It can be dynamically altered.
 
Yes, it does. But you don't know what this means. This doesn't mean
that the spin-count isn't adjustable. This does mean that it isn't
adaptive, i.e. self-adjusted, like under Linux.
Bonita Montero <Bonita.Montero@gmail.com>: May 12 10:06PM +0200

> Why do you say that? Humm...
> https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-setcriticalsectionspincount
> This allows the spin count to be modified.
 
You're so stupid, dude.
That's the same what my code allows.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 12 06:10PM -0700

On 5/12/2020 1:35 PM, Bonita Montero wrote:
>> then understand your corrections?
 
> The code is short and simple and you even have the time to write
> a lot of nonsense-postings here.
 
lol. Anyway, thank you for triggering me to bust out Relacy. Its making
think of some older experiments.
Bonita Montero <Bonita.Montero@gmail.com>: May 12 02:17PM +0200

> not atomic, and neither happens before the other, except for the
> special case for signal handlers described below. Any such data
> race results in undefined behavior."
 
The C-standard isn't defining what we're talking about here.
The Wikipedia should be more definitive.
Bonita Montero <Bonita.Montero@gmail.com>: May 13 08:07AM +0200

>> Sorry, that's as stupid as to debug hello world.
 
> Yet you had to correct it multiple times...
 
At the beginning there were some bugs.
But most times the code wasn't "corrected" because of bugs.
Bonita Montero <Bonita.Montero@gmail.com>: May 12 10:30PM +0200

>>> time always.
 
>> Doesn't change what I said.
 
> lol.
 
You don't even understand the simplest statements from this thread.
Bonita Montero <Bonita.Montero@gmail.com>: May 12 10:08PM +0200

> Bonita, calm down and realize that you are having some real trouble with
> understanding adaptive mutexs. You don't "seem" to have any experience
> with them.
 
My mutex exactly does the same what the Windows mutex does.
 
> Btw, please run your code through a race detector to kill off the bugs.
 
Tell me what the bugs are. There aren't any.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 12 01:35PM -0700

On 5/12/2020 1:28 PM, Bonita Montero wrote:
> each iteration on my CPU. On other CPUs this might be different. So
> mayme someone here could supply some inline-assembly to make the
> code of spendCycles timing-equivalent for Li
 
If this is the most recent code, please post it in a brand new thread.
This thread is getting deep (heavily nested) and harder and harder to read.
 
 
[... snip code ...]
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 12 12:59PM -0700

On 5/11/2020 11:49 PM, Bonita Montero wrote:
>> and PTHREAD_MUTEX_ADAPTIVE_NP is fastest there for most things.
 
> Write a benchmark.
> Or look at Windows. Windows has a fixed spin-count. [...]
 
https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-setcriticalsectionspincount
 
[...]
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 12 02:26PM -0700

On 5/12/2020 1:36 PM, Bonita Montero wrote:
>> Then I should have some time today, or perhaps tomorrow to port
>> it over to Relacy. ...
 
> Sorry, that's as stupid as to debug hello world.
 
Yet you had to correct it multiple times...
Bonita Montero <Bonita.Montero@gmail.com>: May 12 04:12PM +0200

> It is C++17 standard and we were talking about your C++ code in
> comp.lang.c++ so why Wikipedia's matters?
 
You are pettifogging. My definition applies to every language.
Think my implmenation would be written in any other language.
Bonita Montero <Bonita.Montero@gmail.com>: May 12 10:19PM +0200

>> I'm pretty sure you haven't read my code.
 
> No. I read where you made some corrections.
 
You make assumptions on my code without reading it.
Bonita Montero <Bonita.Montero@gmail.com>: May 12 08:51AM +0200

So you can download the MSVC-2019-project here:
https://fil.email/ffP0ghTV
Compile it and give me the parameters that prove
your assumptions.
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.

No comments: