Sunday, February 16, 2020

Digest for comp.lang.c++@googlegroups.com - 15 updates in 8 topics

aminer68@gmail.com: Feb 16 03:19PM -0800

Hello,
 
 
More precision about my new invention of my Fast Mutex..
 
I have just made a mistake when i said the following about my Fast Mutex:
 
4- Very good fast path performance (it has the same performance as the
scalable MCS lock when there is contention.)
 
Because with my Fast Mutex you can tune fairness, so when you choose to
be more unfair, it can be much faster than MCS lock when there is contention by being Starvation-free. So i think that my invention of my Fast Mutex is the best, here is its characteristics:
 
1- Starvation-free
2- Tunable fairness
3- It keeps efficiently and very low the cache coherence traffic
4- Very good fast path performance
5- And it has a good preemption tolerance.
 
Read my previous thoughts to understand:
 
About fair and unfair locking..
 
I have just read the following lead engineer at Amazon:
 
Highly contended and fair locking in Java
 
https://brooker.co.za/blog/2012/09/10/locking.html
 
So as you are noticing that you can use unfair locking that can have starvation or fair locking that is slower than unfair locking.
 
I think that Microsoft synchronization objects like the Windows critical section uses unfair locking, but they still can have starvation.
 
But i think that this not the good way to do, because i am an inventor and i have invented a scalable Fast Mutex that is much more powerful , because with my Fast Mutex you are capable to tune the "fairness" of the lock, and my Fast Mutex is capable of more than that, read about it on my following thoughts:
 
More about research and software development..
 
I have just looked at the following new video:
 
Why is coding so hard...
 
https://www.youtube.com/watch?v=TAAXwrgd1U8
 
 
I am understanding this video, but i have to explain my work:
 
I am not like this techlead in the video above, because i am also an "inventor" that has invented many scalable algorithms and there implementions, i am also inventing effective abstractions, i give you an example:
 
Read the following of the senior research scientist that is called Dave Dice:
 
Preemption tolerant MCS locks
 
https://blogs.oracle.com/dave/preemption-tolerant-mcs-locks
 
As you are noticing he is trying to invent a new lock that is preemption tolerant, but his lock lacks some important characteristics, this is why i have just invented a new Fast Mutex that is adaptative and that is much much better and i think mine is the "best", and i think you will not find it anywhere, my new Fast Mutex has the following characteristics:
 
1- Starvation-free
2- Tunable fairness
3- It keeps efficiently and very low the cache coherence traffic
4- Very good fast path performance
5- And it has a good preemption tolerance.
 
this is how i am an "inventor", and i have also invented other scalable algorithms such as a scalable reference counting with efficient support for weak references, and i have invented a fully scalable Threadpool, and i have also invented a Fully scalable FIFO queue, and i have also invented other scalable algorithms and there implementations, and i think i will sell some of them to Microsoft or to Google or Embarcadero or such software companies.
 
Thank you,
Amine Moulay Ramdane.
aminer68@gmail.com: Feb 16 03:06PM -0800

Hello,
 
 
Read again, i correct about fair and unfair locking..
 
About fair and unfair locking..
 
I have just read the following lead engineer at Amazon:
 
Highly contended and fair locking in Java
 
https://brooker.co.za/blog/2012/09/10/locking.html
 
So as you are noticing that you can use unfair locking that can have starvation or fair locking that is slower than unfair locking.
 
I think that Microsoft synchronization objects like the Windows critical section uses unfair locking, but they still can have starvation.
 
But i think that this not the good way to do, because i am an inventor and i have invented a scalable Fast Mutex that is much more powerful , because with my Fast Mutex you are capable to tune the "fairness" of the lock, and my Fast Mutex is capable of more than that, read about it on my following thoughts:
 
More about research and software development..
 
I have just looked at the following new video:
 
Why is coding so hard...
 
https://www.youtube.com/watch?v=TAAXwrgd1U8
 
 
I am understanding this video, but i have to explain my work:
 
I am not like this techlead in the video above, because i am also an "inventor" that has invented many scalable algorithms and there implementions, i am also inventing effective abstractions, i give you an example:
 
Read the following of the senior research scientist that is called Dave Dice:
 
Preemption tolerant MCS locks
 
https://blogs.oracle.com/dave/preemption-tolerant-mcs-locks
 
As you are noticing he is trying to invent a new lock that is preemption tolerant, but his lock lacks some important characteristics, this is why i have just invented a new Fast Mutex that is adaptative and that is much much better and i think mine is the "best", and i think you will not find it anywhere, my new Fast Mutex has the following characteristics:
 
1- Starvation-free
2- Tunable fairness
3- It keeps efficiently and very low the cache coherence traffic
4- Very good fast path performance (it has the same performance as the
scalable MCS lock when there is contention.)
5- And it has a good preemption tolerance.
 
this is how i am an "inventor", and i have also invented other scalable algorithms such as a scalable reference counting with efficient support for weak references, and i have invented a fully scalable Threadpool, and i have also invented a Fully scalable FIFO queue, and i have also invented other scalable algorithms and there implementations, and i think i will sell some of them to Microsoft or to Google or Embarcadero or such software companies.
 
Thank you,
Amine Moulay Ramdane.
aminer68@gmail.com: Feb 16 03:02PM -0800

Hello,
 
 
About fair and unfair locking..
 
I have just read the following lead engineer at Amazon:
 
Highly contended and fair locking in Java
 
https://brooker.co.za/blog/2012/09/10/locking.html
 
So as you are noticing that you can use unfair locking that can have starvation or fair locking that is slower than unfair locking.
 
I think that Microsoft synchronization objects like the Windows critical section uses unfair locking, but they still can have starvation.
 
But i think that this not the good way to do, because i am an inventor and i have invented a scalable Fast Mutex that is much more powerful , because with my Fast Mutex you are capable to tune the "fairness" of the lock, and my Fast Mutex s capable of more that that, read about it on my following thoughts:
 
 
More about research and software development..
 
I have just looked at the following new video:
 
Why is coding so hard...
 
https://www.youtube.com/watch?v=TAAXwrgd1U8
 
 
I am understanding this video, but i have to explain my work:
 
I am not like this techlead in the video above, because i am also an "inventor" that has invented many scalable algorithms and there implementions, i am also inventing effective abstractions, i give you an example:
 
Read the following of the senior research scientist that is called Dave Dice:
 
Preemption tolerant MCS locks
 
https://blogs.oracle.com/dave/preemption-tolerant-mcs-locks
 
As you are noticing he is trying to invent a new lock that is preemption tolerant, but his lock lacks some important characteristics, this is why i have just invented a new Fast Mutex that is adaptative and that is much much better and i think mine is the "best", and i think you will not find it anywhere, my new Fast Mutex has the following characteristics:
 
1- Starvation-free
2- Tunable fairness
3- It keeps efficiently and very low the cache coherence traffic
4- Very good fast path performance (it has the same performance as the
scalable MCS lock when there is contention.)
5- And it has a good preemption tolerance.
 
this is how i am an "inventor", and i have also invented other scalable algorithms such as a scalable reference counting with efficient support for weak references, and i have invented a fully scalable Threadpool, and i have also invented a Fully scalable FIFO queue, and i have also invented other scalable algorithms and there implementations, and i think i will sell some of them to Microsoft or to Google or Embarcadero or such software companies.
 
Thank you,
Amine Moulay Ramdane.
gazelle@shell.xmission.com (Kenny McCormack): Feb 16 03:42PM

In article <b8b5e400-09ee-4121-bca7-4d9122dc60d0@googlegroups.com>,
 
>Please do not post about your Pascal code here, it is not topical.
>In world there are programs that are written in Pascal but we are
>not participating in any of those projects.
 
Note also that this is also an English language group - something that
Leader Kiki frequently points out. Please write in English.
 
(Not in Pigeon-speak)
 
--
Q: How much do dead batteries cost?
 
A: Nothing. They are free of charge.
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Feb 16 02:38PM -0800


> Please do not post about your Pascal code here, it is not topical.
> In world there are programs that are written in Pascal but we are
> not participating in any of those projects.
 
Please do not waste time asking Amine Moulay Ramdane not to post. This
person has a very long history of posting hundreds of off-topic
articles. Asking him to stop has never had any effect. I suggest a
killfile (which may have to be updated as he changes his email address).
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
Jorgen Grahn <grahn+nntp@snipabacken.se>: Feb 16 08:27AM

On Sat, 2020-02-15, Frederick Gotham wrote:
 
> Are you arguing, in general, that a person who has good intentions
> should refrain from doing something if there is the possibility that
> an observer might think that they are up to no good?
 
I think he's just saying fewer people will use your software if it
needs root access and at the same time behaves oddly.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Jorgen Grahn <grahn+nntp@snipabacken.se>: Feb 16 08:44AM

On Thu, 2020-02-13, Jorgen Grahn wrote:
>> this.
 
> You're wrong; there's at least one standard Unix way of doing it, and
> maybe some Linux-specific ones, too.
 
I was wrong about this, because I didn't read the question properly.
 
I was thinking about a user elevating her privileges by executing a
setuid binary or a setgid binary, or doing something similar with
capabilities(7). This includes running su(1), sudo and similar.
 
You however wanted to elevate the privileges of an existing /process/,
and I have no idea there. I hope it's not possible, except by
exec()ing su(1) or sudo.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Jorgen Grahn <grahn+nntp@snipabacken.se>: Feb 16 09:06AM

On Fri, 2020-02-14, Melzzzzz wrote:
>> change this. If my program is run as a normal user then I want the
>> user to be prompted to elevate to Administrator (or "root") and to
>> input their password as necessary.
...
 
>> Any advice or ideas on this?
 
> https://wiki.wireshark.org/CaptureSetup/CapturePrivileges
 
"Wireshark has implemented Privilege Separation which means that
the Wireshark GUI (or the tshark CLI) can run as a normal user
while the dumpcap capture utility runs as root. This can be
achieved by installing dumpcap setuid root. The advantage of this
solution is that while dumpcap is run as root the vast majority of
Wireshark's code is run as a normal user (where it can do much
less damage)."
 
FWIW, I find what they're doing unacceptable. Their main installation
option lets any local user spy on any other local user's network
traffic, via the setuid 'dumpcap' helper. (Happily Debian doesn't
install wireshark that way by default.)
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Bonita Montero <Bonita.Montero@gmail.com>: Feb 16 10:27AM +0100

> option lets any local user spy on any other local user's network
> traffic, via the setuid 'dumpcap' helper. (Happily Debian doesn't
> install wireshark that way by default.)
 
I think it's ok if it it's the root's decision.
David Brown <david.brown@hesbynett.no>: Feb 16 10:42AM +0100

On 15/02/2020 19:02, Frederick Gotham wrote:
 
> Are you arguing, in general, that a person who has good intentions
> should refrain from doing something if there is the possibility that
> an observer might think that they are up to no good?
 
No, of course not. That would be a ridiculous generalisation.
 
But I /am/ arguing you should not do something that is entirely
unnecessary for your good intentions, and uses techniques that are
primarily useful for bad intentions. If we were plotting these aspects
of your idea on a graph with one axis on the "looks like good intentions
vs. looks like bad intentions" and the other as "tried-and-tested,
standard and familiar solution to the problem vs. unusual and
experimental solution", then I am suggesting you stay out of the awkward
corner. I am not suggesting you stay off the graph altogether.
 
 
> How do you feel about BitTorrent? Should people who have good
> intentions avoid using BitTorrent for fear that an observer will
> think that they're doing something wrong?
 
That is a very different case. For one thing, there were perfectly
good, legitimate uses for the technology - it was a great way to spread
network costs for large downloads. And any system which provided that
feature for good purposes would also allow it for bad purposes. (Your
suggested solution is not a good one, and better choices can't be abused
for bad purposes.)
 
But Bittorrent users should be aware that the huge majority of
Bittorrent traffic is for unlawful (or at least suspicious, given that
laws vary from place to place) activity.
 
 
> anything invasive of privacy or copyright (e.g. copying a user's
> personal collection of short stories, or online banking passwords, to
> a remote server). My program is benign.
 
I realise it is benign. That does not mean it is a good idea to use
obfuscation techniques that are classic signs of malware.
 
> dishonest. It's not like I'm trying to gain root access by deception
> -- I want the user to willingly enter their password to grant
> access.
 
I think you are wrong here. Yes, it matters that you are using such
techniques, for many reasons:
 
1. You would be alienating potential users - they will avoid your
software as it uses suspicious techniques.
 
2. You may cause conflict with protection mechanisms (AppArmor, or other
security systems). This means people can't use your software - or
worse, they must open their system to /real/ malware by disabling their
protections.
 
3. You encourage people to think it's okay to enter their root password
when a program asks for it. That is a bad precedence to set.
 
4. You show script kiddies how to make malware, since they can copy your
source and put their own malware in it.
 
You are trying to claim that the ends justify the means. I don't agree
with that. But whether you do agree with it or not, I hope you accept
that when there are simpler, safer and better ways to get the end
result, then these are preferable.
 
 
> I think you're being overly and unnecessarily restrictive by advising
> people not to do something simply because it resembles something
> bad.
 
It's your software and your choice. I'll give the advice that I think
is right, but it's up to you to decide.
David Brown <david.brown@hesbynett.no>: Feb 16 10:48AM +0100

On 16/02/2020 10:27, Bonita Montero wrote:
>> traffic, via the setuid 'dumpcap' helper.  (Happily Debian doesn't
>> install wireshark that way by default.)
 
> I think it's ok if it it's the root's decision.
 
That might be okay if you have a tightly run network where only IT staff
have root access to machines. If each user has root access to their own
machines, then this wireshark policy makes it relatively easy to spy on
other traffic on the network.
 
However, there are so many ways that someone with nefarious plans could
spy on traffic on most local networks, that I think the Wireshark case
is not a problem.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 16 09:17AM +0100

On 15.02.2020 14:56, Tim Rentsch wrote:
> also in C++ but I am less well-versed in the C++ standard than
> the C standard). The reason is size_t is not required to be at
> least as wide as int, so the ~ could produce a negative value.
 
Interesting point.
 
Does any C or C++ implemention with sizeof(size_t) < sizeof(int) exist,
or has any such implementation existed?
 
Fix: `~(size_t(-1)/2u)`. But the question is, since code is about
communicating to humans, does this communicate the right thing?
 
- Alf
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Feb 15 08:57PM -0500

Bonita Montero wrote:
>> return -(!((code & (_XABORT_RETRY | _XABORT_EXPLICIT)) ==
>> _XABORT_RETRY));
 
> That's obfuscation.
To an extent -- and that was the point (that following some advice on
style could further mess up already messy code).
> I like the ternary operator and in contrast to C++ you can do
> some nice  things like this "++(xyz == CMP ? a : b)" with it.
Now THAT is a) obfuscation and b) irrelevant to your TM idea.
> That's compact and not unreadable like the above.
The comparison is meaningless due to b) above.
Bonita Montero <Bonita.Montero@gmail.com>: Feb 16 08:09AM +0100

>> I like the ternary operator and in contrast to C++ you can do
>> some nice  things like this "++(xyz == CMP ? a : b)" with it.
 
> Now THAT is a) obfuscation and b) irrelevant to your TM idea.
 
It's unusual, but readable, so no obfuscation.
aminer68@gmail.com: Feb 15 03:58PM -0800

Hello..
 
 
About Turing completeness and parallel programming..
 
You have to know that a Turing-complete system can be proven mathematically to be capable of performing any possible calculation or computer program.
 
So now you are understanding what is the power of "expressiveness" that
is Turing-complete.
 
For example i am working with the Tool that is called "Tina"(read about it below), it is a powerful tool that permits to work on Petri nets and be able to know about the boundedness and liveness of Petri nets, for example Tina supports Timed Petri nets that are Turing-complete , so the power of there expressiveness is Turing-complete, but i think this level of expressiveness is good for parallel programming and such, but
it is not an efficient high level expressiveness. But still Petri nets are good for parallel programming.
 
Read the rest to know more:
 
About deadlocks and race conditions in parallel programming..
 
I have just read the following paper:
 
Deadlock Avoidance in Parallel Programs with Futures
 
https://cogumbreiro.github.io/assets/cogumbreiro-gorn.pdf
 
So as you are noticing you can have deadlocks in parallel programming
by introducing circular dependencies among tasks waiting on future values or you can have deadlocks by introducing circular dependencies among tasks waiting on windows event objects or such synchronisation objects, so you have to have a general tool that detects deadlocks,
but if you are noticing that the tool called Valgrind for C++
can detect deadlocks only happening from Pthread locks , read
the following to notice it:
 
http://valgrind.org/docs/manual/hg-manual.html#hg-manual.lock-orders
 
So this is not good, so you have to have a general way that permits
to detect deadlocks on locks , mutexes, and deadlocks from introducing circular dependencies among tasks waiting on future values or deadlocks you may have deadlocks by introducing circular dependencies among tasks waiting on windows event objects or such synchronisation objects etc.
this is why i have talked before about this general way that detects deadlocks, and here it is, read my following thoughts:
 
Yet more precision about the invariants of a system..
 
I was just thinking about Petri nets , and i have studied more
Petri nets, they are useful for parallel programming, and
what i have noticed by studying them, is that there is two methods
to prove that there is no deadlock in the system, there is the
structural analysis with place invariants that you have to mathematically find, or you can use the reachability tree, but we have to notice that the structural analysis of Petri nets learns you more, because it permits you to prove that there is no deadlock in the system, and the place invariants are mathematically calculated by the following
system of the given Petri net:
 
Transpose(vector) * Incidence matrix = 0
 
So you apply the Gaussian Elimination or the Farkas algorithm to
the incidence matrix to find the Place invariants, and as you will
notice those place invariants calculations of the Petri nets look
like Markov chains in mathematics, with there vector of probabilities
and there transition matrix of probabilities, and you can, using
Markov chains mathematically calculate where the vector of probabilities
will "stabilize", and it gives you a very important information, and
you can do it by solving the following mathematical system:
 
Unknown vector1 of probabilities * transition matrix of probabilities = Unknown vector1 of probabilities.
 
Solving this system of equations is very important in economics and
other fields, and you can notice that it is like calculating the
invariants , because the invariant in the system above is the
vector1 of probabilities that is obtained, and this invariant,
like in the invariants of the structural analysis of Petri nets,
gives you a very important information about the system, like where
market shares will stabilize that is calculated this way in economics.
 
About reachability analysis of a Petri net..
 
As you have noticed in my Petri nets tutorial example (read below),
i am analysing the liveness of the Petri net, because there is a rule
that says:
 
If a Petri net is live, that means that it is deadlock-free.
 
Because reachability analysis of a Petri net with Tina
gives you the necessary information about boundedness and liveness
of the Petri net. So if it gives you that the Petri net is "live" , so
there is no deadlock in it.
 
Tina and Partial order reduction techniques..
 
With the advancement of computer technology, highly concurrent systems
are being developed. The verification of such systems is a challenging
task, as their state space grows exponentially with the number of processes. Partial order reduction is an effective technique to address this problem. It relies on the observation that the effect of executing transitions concurrently is often independent of their ordering.
 
Tina is using "partial-order" reduction techniques aimed at preventing
combinatorial explosion, Read more here to notice it:
 
http://projects.laas.fr/tina/papers/qest06.pdf
 
About modelizations and detection of race conditions and deadlocks
in parallel programming..
 
I have just taken further a look at the following project in Delphi
called DelphiConcurrent by an engineer called Moualek Adlene from France:
 
https://github.com/moualek-adlene/DelphiConcurrent/blob/master/DelphiConcurrent.pas
 
And i have just taken a look at the following webpage of Dr Dobb's journal:
 
Detecting Deadlocks in C++ Using a Locks Monitor
 
https://www.drdobbs.com/detecting-deadlocks-in-c-using-a-locks-m/184416644
 
And i think that both of them are using technics that are not as good
as analysing deadlocks with Petri Nets in parallel applications ,
for example the above two methods are only addressing locks or mutexes
or reader-writer locks , but they are not addressing semaphores
or event objects and such other synchronization objects, so they
are not good, this is why i have written a tutorial that shows my
methodology of analysing and detecting deadlocks in parallel applications with Petri Nets, my methodology is more sophisticated because it is a generalization and it modelizes with Petri Nets the broader range of synchronization objects, and in my tutorial i will add soon other synchronization objects, you have to look at it, here it is:
 
https://sites.google.com/site/scalable68/how-to-analyse-parallel-applications-with-petri-nets
 
You have to get the powerful Tina software to run my Petri Net examples
inside my tutorial, here is the powerful Tina software:
 
http://projects.laas.fr/tina/
 
Also to detect race conditions in parallel programming you have to take
a look at the following new tutorial that uses the powerful Spin tool:
 
https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html
 
This is how you will get much more professional at detecting deadlocks
and race conditions in parallel programming.
 
 
Thank you,
Amine Moulay Ramdane.
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:

Post a Comment

Subscribe to: Post Comments (Atom)