Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #6954 > unrolled thread

Here is my new invention

Back to article view | Back to comp.programming.threads

Contents

  Here is my new invention Amine Moulay Ramdane <aminer68@gmail.com> - 2021-10-10 11:34 -0700
    Re: Here is my new invention Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-10 20:48 +0200
      Re: Here is my new invention Amine Moulay Ramdane <aminer68@gmail.com> - 2021-10-10 12:02 -0700
      Re: Here is my new invention Amine Moulay Ramdane <aminer68@gmail.com> - 2021-10-10 12:09 -0700
        Re: Here is my new invention Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-11 00:14 +0000
        Re: Here is my new invention Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-11 08:11 +0200
      Re: Here is my new invention Amine Moulay Ramdane <aminer68@gmail.com> - 2021-10-10 12:11 -0700
      Re: Here is my new invention Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-11 00:11 +0000

#6954 — Here is my new invention

Hello,


I am a white arab, and i think i am smart since i have also
invented many scalable algorithms and algorithms..

Here is my new invention of a fast, and scalable and starvation-free and fair and lightweight Multiple-Readers-Exclusive-Writer Lock called LW_RWLockX, and now i have included two units that are called MREWEx and LighweightMREWEx that include TMultiReadExclusiveWriteSynchronizer and TLightweightMREW classes that are scalable and starvation-free and fair since they are using my Scalable LW_RWLockX that is starvation-free and fair, also BeginRead() and BeginWrite() of LightweightMREWEx are reentrant (recursive), so in other words, if a thread already called BeginWrite(), it can call BeginWrite() again and it will succeed and it will not deadlock, and the same applies to BeginRead(), please take a look at them inside the source code of my units.

You can download it from my website here:

https://sites.google.com/site/scalable68/new-variants-of-scalable-rwlocks

Here is also my way of how i am becoming rich:

First i want to say that i have passed four IQ tests and some of them
are certified and i have scored high, so i am highly smart, second,
my methodology is also that i am reading many PhD papers of researchers and i am seeking the weaknesses of them, and i have found many weaknesses on those PhD papers and from those weaknesses i have invented many software scalable algorithms and algorithms and i have invented some powerful software tools for parallelism etc., so i give you an example of one of my invention that is: A Scalable reference counting with efficient support for weak references, so that you understand that i am truthful, here it is:

https://sites.google.com/site/scalable68/scalable-reference-counting-with-efficient-support-for-weak-references

But the truth is that i have invented many scalable algorithms such
as this one, and i have made public some of them. And here is another example of how i am inventive and creative in operational research too, i have just read the following book (and of other books like it) of a PhD researcher about operational research and capacity planning, here they are:

Performance by Design: Computer Capacity Planning by Example

https://www.amazon.ca/Performance-Design-Computer-Capacity-Planning/dp/0130906735

So i have just found that there methodologies of those PhD researchers for the E-Business service don't work, because they are doing calculations for a given arrival rate that is statistically and empirically measured from the behavior of customers, but i think that it is not correct, so i am being inventive and i have come with my new methodology that fixes the arrival rate from the data by using an hyperexponential service distribution(and it is mathematical) since it is also good for Denial-of-Service (DoS) attacks and i will write a powerful book about it that will teach my new methodology and i will also explain the mathematics behind it and i will sell it, and my new methodology will work for cloud computing and for computer servers.

You can read more about my education and my way of doing here:

And here is more proof of the fact that i have invented many scalable algorithms and algorithms:

https://groups.google.com/g/comp.programming.threads/c/V9Go8fbF10k


Thank you,
Amine Moulay Ramdane.

[toc] | [next] | [standalone]

#6955

Am 10.10.2021 um 20:34 schrieb Amine Moulay Ramdane:
> Hello,
> 
> 
> I am a white arab, and i think i am smart since i have also
> invented many scalable algorithms and algorithms..
> 
> Here is my new invention of a fast, and scalable and starvation-free and fair and lightweight Multiple-Readers-Exclusive-Writer Lock called LW_RWLockX, and now i have included two units that are called MREWEx and LighweightMREWEx that include TMultiReadExclusiveWriteSynchronizer and TLightweightMREW classes that are scalable and starvation-free and fair since they are using my Scalable LW_RWLockX that is starvation-free and fair, also BeginRead() and BeginWrite() of LightweightMREWEx are reentrant (recursive), so in other words, if a thread already called BeginWrite(), it can call BeginWrite() again and it will succeed and it will not deadlock, and the same applies to BeginRead(), please take a look at them inside the source code of my units.

You're an idiot !

Multiple reader, exlusive writer locks are *never* starvation-free.
Readers can hold the lock infinetely and weiters as well.

[toc] | [prev] | [next] | [standalone]

#6956

On Sunday, October 10, 2021 at 2:48:14 PM UTC-4, Bonita Montero wrote:
> Am 10.10.2021 um 20:34 schrieb Amine Moulay Ramdane: 
> > Hello, 
> > 
> > 
> > I am a white arab, and i think i am smart since i have also 
> > invented many scalable algorithms and algorithms.. 
> > 
> > Here is my new invention of a fast, and scalable and starvation-free and fair and lightweight Multiple-Readers-Exclusive-Writer Lock called LW_RWLockX, and now i have included two units that are called MREWEx and LighweightMREWEx that include TMultiReadExclusiveWriteSynchronizer and TLightweightMREW classes that are scalable and starvation-free and fair since they are using my Scalable LW_RWLockX that is starvation-free and fair, also BeginRead() and BeginWrite() of LightweightMREWEx are reentrant (recursive), so in other words, if a thread already called BeginWrite(), it can call BeginWrite() again and it will succeed and it will not deadlock, and the same applies to BeginRead(), please take a look at them inside the source code of my units.
> You're an idiot ! 
> 
> Multiple reader, exlusive writer locks are *never* starvation-free. 
> Readers can hold the lock infinetely and weiters as well.

I think you are making a mistake and you are not understanding what 
is that a Multiple-Readers-Exclusive-Writer Lock is starvation-free, 
what i mean by starvation-free is that in my algorithm the readers 
don't starve the writers and the writers don't starve the readers, 
it is what we call starvation-free, and i think my invention is scalable 
and starvation-free and fair.


Thank you,
Amine Moulay Ramdane.

[toc] | [prev] | [next] | [standalone]

#6957

On Sunday, October 10, 2021 at 2:48:14 PM UTC-4, Bonita Montero wrote:
> Am 10.10.2021 um 20:34 schrieb Amine Moulay Ramdane: 
> > Hello, 
> > 
> > 
> > I am a white arab, and i think i am smart since i have also 
> > invented many scalable algorithms and algorithms.. 
> > 
> > Here is my new invention of a fast, and scalable and starvation-free and fair and lightweight Multiple-Readers-Exclusive-Writer Lock called LW_RWLockX, and now i have included two units that are called MREWEx and LighweightMREWEx that include TMultiReadExclusiveWriteSynchronizer and TLightweightMREW classes that are scalable and starvation-free and fair since they are using my Scalable LW_RWLockX that is starvation-free and fair, also BeginRead() and BeginWrite() of LightweightMREWEx are reentrant (recursive), so in other words, if a thread already called BeginWrite(), it can call BeginWrite() again and it will succeed and it will not deadlock, and the same applies to BeginRead(), please take a look at them inside the source code of my units.
> You're an idiot ! 
> 
> Multiple reader, exlusive writer locks are *never* starvation-free. 
> Readers can hold the lock infinetely and weiters as well.

This holding the lock infinetely and wreiters is not counted, since 
you have just to use it correctly and avoid this case, 
I think you are making a mistake and you are not understanding what
is that a Multiple-Readers-Exclusive-Writer Lock is starvation-free,
what i mean by starvation-free is that in my algorithm the readers
don't starve the writers and the writers don't starve the readers,
it is what we call starvation-free, and i think my invention is scalable
and starvation-free and fair.


Thank you,
Amine Moulay Ramdane.

[toc] | [prev] | [next] | [standalone]

#6964

On 2021-10-10, Amine Moulay Ramdane <aminer68@gmail.com> wrote:
> On Sunday, October 10, 2021 at 2:48:14 PM UTC-4, Bonita Montero wrote:
>> Am 10.10.2021 um 20:34 schrieb Amine Moulay Ramdane: 
>> > Hello, 
>> > 
>> > 
>> > I am a white arab, and i think i am smart since i have also 
>> > invented many scalable algorithms and algorithms.. 
>> > 
>> > Here is my new invention of a fast, and scalable and starvation-free and
>> > fair and lightweight Multiple-Readers-Exclusive-Writer Lock called
>> > LW_RWLockX, and now i have included two units that are called MREWEx and
>> > LighweightMREWEx that include TMultiReadExclusiveWriteSynchronizer and
>> > TLightweightMREW classes that are scalable and starvation-free and fair
>> > since they are using my Scalable LW_RWLockX that is starvation-free and
>> > fair, also BeginRead() and BeginWrite() of LightweightMREWEx are reentrant
>> > (recursive), so in other words, if a thread already called BeginWrite(),
>> > it can call BeginWrite() again and it will succeed and it will not
>> > deadlock, and the same applies to BeginRead(), please take a look at them
>> > inside the source code of my units.
>> You're an idiot ! 
>> 
>> Multiple reader, exlusive writer locks are *never* starvation-free. 
>> Readers can hold the lock infinetely and weiters as well.
>
> This holding the lock infinetely and wreiters is not counted, since 
> you have just to use it correctly and avoid this case, 
If used correctly you don't need any lock :P
Locks are for synchronization, which is not good thing :P

>
>
> Thank you,
> Amine Moulay Ramdane.
Bravo Amine!
LOVE&PEACE

-- 

7-77-777
Evil Sinner!
with software, you repeat same experiment, expecting different results...

[toc] | [prev] | [next] | [standalone]

#6969

Am 10.10.2021 um 21:09 schrieb Amine Moulay Ramdane:
> On Sunday, October 10, 2021 at 2:48:14 PM UTC-4, Bonita Montero wrote:
>> Am 10.10.2021 um 20:34 schrieb Amine Moulay Ramdane:
>>> Hello,
>>>
>>>
>>> I am a white arab, and i think i am smart since i have also
>>> invented many scalable algorithms and algorithms..
>>>
>>> Here is my new invention of a fast, and scalable and starvation-free and fair and lightweight Multiple-Readers-Exclusive-Writer Lock called LW_RWLockX, and now i have included two units that are called MREWEx and LighweightMREWEx that include TMultiReadExclusiveWriteSynchronizer and TLightweightMREW classes that are scalable and starvation-free and fair since they are using my Scalable LW_RWLockX that is starvation-free and fair, also BeginRead() and BeginWrite() of LightweightMREWEx are reentrant (recursive), so in other words, if a thread already called BeginWrite(), it can call BeginWrite() again and it will succeed and it will not deadlock, and the same applies to BeginRead(), please take a look at them inside the source code of my units.
>> You're an idiot !
>>
>> Multiple reader, exlusive writer locks are *never* starvation-free.
>> Readers can hold the lock infinetely and weiters as well.
> 
> This holding the lock infinetely and wreiters is not counted, since
> you have just to use it correctly and avoid this case, ...

I just falsified your assumtion that a multiple reader,
exlusive writer lock could be starvation-free by itself.

[toc] | [prev] | [next] | [standalone]

#6958

On Sunday, October 10, 2021 at 2:48:14 PM UTC-4, Bonita Montero wrote:
> Am 10.10.2021 um 20:34 schrieb Amine Moulay Ramdane: 
> > Hello, 
> > 
> > 
> > I am a white arab, and i think i am smart since i have also 
> > invented many scalable algorithms and algorithms.. 
> > 
> > Here is my new invention of a fast, and scalable and starvation-free and fair and lightweight Multiple-Readers-Exclusive-Writer Lock called LW_RWLockX, and now i have included two units that are called MREWEx and LighweightMREWEx that include TMultiReadExclusiveWriteSynchronizer and TLightweightMREW classes that are scalable and starvation-free and fair since they are using my Scalable LW_RWLockX that is starvation-free and fair, also BeginRead() and BeginWrite() of LightweightMREWEx are reentrant (recursive), so in other words, if a thread already called BeginWrite(), it can call BeginWrite() again and it will succeed and it will not deadlock, and the same applies to BeginRead(), please take a look at them inside the source code of my units.
> You're an idiot ! 
> 
> Multiple reader, exlusive writer locks are *never* starvation-free. 
> Readers can hold the lock infinetely and weiters as well.


On Sunday, October 10, 2021 at 2:48:14 PM UTC-4, Bonita Montero wrote:
> Am 10.10.2021 um 20:34 schrieb Amine Moulay Ramdane: 
>> Hello, 
>>
>>
>> I am a white arab, and i think i am smart since i have also 
>> invented many scalable algorithms and algorithms.. 
>>
>> Here is my new invention of a fast, and scalable and starvation-free and fair and lightweight Multiple-Readers-Exclusive-Writer Lock called LW_RWLockX, and now i have included two units that are called MREWEx and LighweightMREWEx that include TMultiReadExclusiveWriteSynchronizer and TLightweightMREW classes that are scalable and starvation-free and fair since they are using my Scalable LW_RWLockX that is starvation-free and fair, also BeginRead() and BeginWrite() of LightweightMREWEx are reentrant (recursive), so in other words, if a thread already called BeginWrite(), it can call BeginWrite() again and it will succeed and it will not deadlock, and the same applies to BeginRead(), please take a look at them inside the source code of my units.
> You're an idiot ! 
>
> Multiple reader, exlusive writer locks are *never* starvation-free. 
> Readers can hold the lock infinetely and weiters as well.

You are an idiot, this holding the lock infinetely is not counted, since 
you have just to use it correctly and avoid this case, 
I think you are making a mistake and you are not understanding what
is that a Multiple-Readers-Exclusive-Writer Lock is starvation-free,
what i mean by starvation-free is that in my algorithm the readers
don't starve the writers and the writers don't starve the readers,
it is what we call starvation-free, and i think my invention is scalable
and starvation-free and fair.


Thank you,
Amine Moulay Ramdane.

[toc] | [prev] | [next] | [standalone]

#6963

On 2021-10-10, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 10.10.2021 um 20:34 schrieb Amine Moulay Ramdane:
>> Hello,
>> 
>> 
>> I am a white arab, and i think i am smart since i have also
>> invented many scalable algorithms and algorithms..
>> 
>> Here is my new invention of a fast, and scalable and starvation-free and
>> fair and lightweight Multiple-Readers-Exclusive-Writer Lock called
>> LW_RWLockX, and now i have included two units that are called MREWEx and
>> LighweightMREWEx that include TMultiReadExclusiveWriteSynchronizer and
>> TLightweightMREW classes that are scalable and starvation-free and fair
>> since they are using my Scalable LW_RWLockX that is starvation-free and
>> fair, also BeginRead() and BeginWrite() of LightweightMREWEx are reentrant
>> (recursive), so in other words, if a thread already called BeginWrite(), it
>> can call BeginWrite() again and it will succeed and it will not deadlock,
>> and the same applies to BeginRead(), please take a look at them inside the
>> source code of my units.
>
> You're an idiot !
>
> Multiple reader, exlusive writer locks are *never* starvation-free.  Readers
> can hold the lock infinetely and weiters as well.
>
Bravo, ON TOPIC!
Sleeper has awaken :p


-- 

7-77-777
Evil Sinner!
with software, you repeat same experiment, expecting different results...

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming.threads

csiph-web