Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Here is my new invention

11 views
Skip to first unread message

Amine Moulay Ramdane

unread,
Oct 10, 2021, 2:34:57 PM10/10/21
to
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.

Bonita Montero

unread,
Oct 10, 2021, 2:48:14 PM10/10/21
to
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.

Amine Moulay Ramdane

unread,
Oct 10, 2021, 3:02:29 PM10/10/21
to
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.

Amine Moulay Ramdane

unread,
Oct 10, 2021, 3:09:47 PM10/10/21
to
On Sunday, October 10, 2021 at 2:48:14 PM UTC-4, Bonita Montero wrote:
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.


Amine Moulay Ramdane

unread,
Oct 10, 2021, 3:11:23 PM10/10/21
to
On Sunday, October 10, 2021 at 2:48:14 PM UTC-4, Bonita Montero wrote:
On Sunday, October 10, 2021 at 2:48:14 PM UTC-4, Bonita Montero wrote:
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.


Branimir Maksimovic

unread,
Oct 10, 2021, 8:11:14 PM10/10/21
to
Bravo, ON TOPIC!
Sleeper has awaken :p


--

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

Branimir Maksimovic

unread,
Oct 10, 2021, 8:14:21 PM10/10/21
to
On 2021-10-10, Amine Moulay Ramdane <amin...@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

Bonita Montero

unread,
Oct 11, 2021, 2:11:44 AM10/11/21
to
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.
0 new messages