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


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

More of my philosophy about my new inventions and more..

Started byAmine Moulay Ramdane <aminer68@gmail.com>
First post2022-02-17 11:02 -0800
Last post2022-02-17 11:49 -0800
Articles 12 — 2 participants

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


Contents

  More of my philosophy about my new inventions and more.. Amine Moulay Ramdane <aminer68@gmail.com> - 2022-02-17 11:02 -0800
    Re: More of my philosophy about my new inventions and more.. Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-17 20:27 +0100
      Re: More of my philosophy about my new inventions and more.. Amine Moulay Ramdane <aminer68@gmail.com> - 2022-02-17 11:41 -0800
        Re: More of my philosophy about my new inventions and more.. Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-17 21:23 +0100
          Re: More of my philosophy about my new inventions and more.. Amine Moulay Ramdane <aminer68@gmail.com> - 2022-02-17 13:28 -0800
            Re: More of my philosophy about my new inventions and more.. Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-18 07:31 +0100
              Re: More of my philosophy about my new inventions and more.. Amine Moulay Ramdane <aminer68@gmail.com> - 2022-02-18 07:58 -0800
                Re: More of my philosophy about my new inventions and more.. Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-18 17:41 +0100
                  Re: More of my philosophy about my new inventions and more.. Amine Moulay Ramdane <aminer68@gmail.com> - 2022-02-18 08:56 -0800
                  Re: More of my philosophy about my new inventions and more.. Amine Moulay Ramdane <aminer68@gmail.com> - 2022-02-18 12:50 -0800
      Re: More of my philosophy about my new inventions and more.. Amine Moulay Ramdane <aminer68@gmail.com> - 2022-02-17 11:44 -0800
        Re: More of my philosophy about my new inventions and more.. Amine Moulay Ramdane <aminer68@gmail.com> - 2022-02-17 11:49 -0800

#7382 — More of my philosophy about my new inventions and more..

FromAmine Moulay Ramdane <aminer68@gmail.com>
Date2022-02-17 11:02 -0800
SubjectMore of my philosophy about my new inventions and more..
Message-ID<90b6051a-ec4a-4e71-a34c-30e303101d9en@googlegroups.com>
Hello,


More of my philosophy about my new inventions and more..

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


I think i am smart, and i say that x86 processor family features a fairly strict memory model that only allows the reorderings of loads before independent store operations, so i have just invented a fully Lockfree FIFO bounded queue and a fully Lockfree LIFO bounded stack that also run on x86 processor family and they are much more powerful than my following inventions:

https://sites.google.com/site/scalable68/lockfree-bounded-lifo-stack-and-fifo-queue

Also i have shared with you my following invention, read about it in my following thoughts:
\
About smartness and about MCS Lock and more..

I have just read the following article from ACM:

Scalability Techniques for Practical Synchronization Primitives

https://queue.acm.org/detail.cfm?id=2698990

Notice how they are speaking about one of the best scalable Lock that we call MCS lock, but i think that CLH and MCS locks are not smart since those scalable Locks are like intrusive, since they have to hide the required parameter to be passed, this is why i think i am smart since i have invented a scalable Lock that is better than MCS Lock since my scalable Lock doesn't require any parameter to be passed, just call the Enter() and Leave() methods and that's all, here it is, read carefully about it in my website here:

https://sites.google.com/site/scalable68/scalable-mlock


I have also just enhanced it more and i will post it soon.

I have also invented many other scalable algorithms and algorithms..



Thank you,
Amine Moulay Ramdane,.

[toc] | [next] | [standalone]


#7383

FromBonita Montero <Bonita.Montero@gmail.com>
Date2022-02-17 20:27 +0100
Message-ID<sum7iu$jmr$1@dont-email.me>
In reply to#7382
Am 17.02.2022 um 20:02 schrieb Amine Moulay Ramdane:
> Hello,
> 
> 
> More of my philosophy about my new inventions and more..
> 
> I am a white arab and i think i am smart since i have also invented many scalable algorithms..
> 
> 
> I think i am smart, and i say that x86 processor family features a fairly strict memory model that only allows the reorderings of loads before independent store operations, so i have just invented a fully Lockfree FIFO bounded queue and a fully Lockfree LIFO bounded stack that also run on x86 processor family and they are much more powerful than my following inventions:

Lock-free queues totally suck since they have to be polled.
The only lock-free structure that is useful is a lock-free stack
for pooing objects and handling back items to a thread like with
modern memory-allocators.

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


#7384

FromAmine Moulay Ramdane <aminer68@gmail.com>
Date2022-02-17 11:41 -0800
Message-ID<709fc805-becd-4074-a827-8563ae5b9d6an@googlegroups.com>
In reply to#7383
On Thursday, February 17, 2022 at 2:27:30 PM UTC-5, Bonita Montero wrote:
> Am 17.02.2022 um 20:02 schrieb Amine Moulay Ramdane: 
> > Hello, 
> > 
> > 
> > More of my philosophy about my new inventions and more.. 
> > 
> > I am a white arab and i think i am smart since i have also invented many scalable algorithms.. 
> > 
> > 
> > I think i am smart, and i say that x86 processor family features a fairly strict memory model that only allows the reorderings of loads before independent store operations, so i have just invented a fully Lockfree FIFO bounded queue and a fully Lockfree LIFO bounded stack that also run on x86 processor family and they are much more powerful than my following inventions:
> Lock-free queues totally suck since they have to be polled. 
> The only lock-free structure that is useful is a lock-free stack 
> for pooing objects and handling back items to a thread like with 
> modern memory-allocators.


Typically, polling a lock-free queue works best when the queue nearly always has entries, a blocking queue works best when the queue is nearly always empty.

The downside of blocking queues is latency, typically of the order of 2-20 uS, due to kernel signaling. This can be mitigated by designing the system so that the work done by the consumer threads on each queued item takes much longer than this interval.

The downside of non-blocking queues is the waste of CPU and memory bandwidth while polling an empty queue. This can be mitigated by designing the system so that the queue is rarely empty.

As already hinted at by commenters, a non-blocking queue is a very bad idea on single-CPU systems.



Thank you,
Amine Moulay Ramdane.

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


#7387

FromBonita Montero <Bonita.Montero@gmail.com>
Date2022-02-17 21:23 +0100
Message-ID<sumarm$mp7$1@dont-email.me>
In reply to#7384
Am 17.02.2022 um 20:41 schrieb Amine Moulay Ramdane:
> On Thursday, February 17, 2022 at 2:27:30 PM UTC-5, Bonita Montero wrote:
>> Am 17.02.2022 um 20:02 schrieb Amine Moulay Ramdane:
>>> Hello,
>>>
>>>
>>> More of my philosophy about my new inventions and more..
>>>
>>> I am a white arab and i think i am smart since i have also invented many scalable algorithms..
>>>
>>>
>>> I think i am smart, and i say that x86 processor family features a fairly strict memory model that only allows the reorderings of loads before independent store operations, so i have just invented a fully Lockfree FIFO bounded queue and a fully Lockfree LIFO bounded stack that also run on x86 processor family and they are much more powerful than my following inventions:
>> Lock-free queues totally suck since they have to be polled.
>> The only lock-free structure that is useful is a lock-free stack
>> for pooing objects and handling back items to a thread like with
>> modern memory-allocators.
> 
> 
> Typically, polling a lock-free queue works best when the queue nearly always has entries, a blocking queue works best when the queue is nearly always empty.

Forget it - no one wants to poll a queue. Having limited
polling with spinning for a while is the best of both sides.

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


#7388

FromAmine Moulay Ramdane <aminer68@gmail.com>
Date2022-02-17 13:28 -0800
Message-ID<9ea34a2d-4a03-4fc2-914c-b159fb679b03n@googlegroups.com>
In reply to#7387
On Thursday, February 17, 2022 at 3:23:22 PM UTC-5, Bonita Montero wrote:
> Am 17.02.2022 um 20:41 schrieb Amine Moulay Ramdane: 
> > On Thursday, February 17, 2022 at 2:27:30 PM UTC-5, Bonita Montero wrote: 
> >> Am 17.02.2022 um 20:02 schrieb Amine Moulay Ramdane: 
> >>> Hello, 
> >>> 
> >>> 
> >>> More of my philosophy about my new inventions and more.. 
> >>> 
> >>> I am a white arab and i think i am smart since i have also invented many scalable algorithms.. 
> >>> 
> >>> 
> >>> I think i am smart, and i say that x86 processor family features a fairly strict memory model that only allows the reorderings of loads before independent store operations, so i have just invented a fully Lockfree FIFO bounded queue and a fully Lockfree LIFO bounded stack that also run on x86 processor family and they are much more powerful than my following inventions: 
> >> Lock-free queues totally suck since they have to be polled. 
> >> The only lock-free structure that is useful is a lock-free stack 
> >> for pooing objects and handling back items to a thread like with 
> >> modern memory-allocators. 
> > 
> > 
> > Typically, polling a lock-free queue works best when the queue nearly always has entries, a blocking queue works best when the queue is nearly always empty.
> Forget it - no one wants to poll a queue. Having limited 
> polling with spinning for a while is the best of both sides.


You have to understand Bonita that lockfree has advantages and disadvantages, so since lock-free queue works best when the queue nearly always has entries, so it is used best on those kind of situations, and for you wanting to have limited 
polling with spinning for a while.., i think you have to understand that lockfree comes with a number of advantages like 
it is not prone to deadlock and it is Pre-emption tolerant so they are good at convoy-avoidance etc. so you have to take 
into account those factors too so that to make a good choice depending on the situation or the context.

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


#7392

FromBonita Montero <Bonita.Montero@gmail.com>
Date2022-02-18 07:31 +0100
Message-ID<sunefv$j1g$1@dont-email.me>
In reply to#7388
Am 17.02.2022 um 22:28 schrieb Amine Moulay Ramdane:
> On Thursday, February 17, 2022 at 3:23:22 PM UTC-5, Bonita Montero wrote:
>> Am 17.02.2022 um 20:41 schrieb Amine Moulay Ramdane:
>>> On Thursday, February 17, 2022 at 2:27:30 PM UTC-5, Bonita Montero wrote:
>>>> Am 17.02.2022 um 20:02 schrieb Amine Moulay Ramdane:
>>>>> Hello,
>>>>>
>>>>>
>>>>> More of my philosophy about my new inventions and more..
>>>>>
>>>>> I am a white arab and i think i am smart since i have also invented many scalable algorithms..
>>>>>
>>>>>
>>>>> I think i am smart, and i say that x86 processor family features a fairly strict memory model that only allows the reorderings of loads before independent store operations, so i have just invented a fully Lockfree FIFO bounded queue and a fully Lockfree LIFO bounded stack that also run on x86 processor family and they are much more powerful than my following inventions:
>>>> Lock-free queues totally suck since they have to be polled.
>>>> The only lock-free structure that is useful is a lock-free stack
>>>> for pooing objects and handling back items to a thread like with
>>>> modern memory-allocators.
>>>
>>>
>>> Typically, polling a lock-free queue works best when the queue nearly always has entries, a blocking queue works best when the queue is nearly always empty.
>> Forget it - no one wants to poll a queue. Having limited
>> polling with spinning for a while is the best of both sides.
> 
> 
> You have to understand Bonita that lockfree has advantages and disadvantages, so since lock-free queue works best when the queue nearly always has entries, ...

This can't be guaranteed since the producer can be scheduled away.
No one uses lock-free queues, they're simply silly.

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


#7393

FromAmine Moulay Ramdane <aminer68@gmail.com>
Date2022-02-18 07:58 -0800
Message-ID<45761848-3160-472d-b056-0de054ff19e1n@googlegroups.com>
In reply to#7392
On Friday, February 18, 2022 at 1:31:31 AM UTC-5, Bonita Montero wrote:
> Am 17.02.2022 um 22:28 schrieb Amine Moulay Ramdane: 
> > On Thursday, February 17, 2022 at 3:23:22 PM UTC-5, Bonita Montero wrote: 
> >> Am 17.02.2022 um 20:41 schrieb Amine Moulay Ramdane: 
> >>> On Thursday, February 17, 2022 at 2:27:30 PM UTC-5, Bonita Montero wrote: 
> >>>> Am 17.02.2022 um 20:02 schrieb Amine Moulay Ramdane: 
> >>>>> Hello, 
> >>>>> 
> >>>>> 
> >>>>> More of my philosophy about my new inventions and more.. 
> >>>>> 
> >>>>> I am a white arab and i think i am smart since i have also invented many scalable algorithms.. 
> >>>>> 
> >>>>> 
> >>>>> I think i am smart, and i say that x86 processor family features a fairly strict memory model that only allows the reorderings of loads before independent store operations, so i have just invented a fully Lockfree FIFO bounded queue and a fully Lockfree LIFO bounded stack that also run on x86 processor family and they are much more powerful than my following inventions: 
> >>>> Lock-free queues totally suck since they have to be polled. 
> >>>> The only lock-free structure that is useful is a lock-free stack 
> >>>> for pooing objects and handling back items to a thread like with 
> >>>> modern memory-allocators. 
> >>> 
> >>> 
> >>> Typically, polling a lock-free queue works best when the queue nearly always has entries, a blocking queue works best when the queue is nearly always empty. 
> >> Forget it - no one wants to poll a queue. Having limited 
> >> polling with spinning for a while is the best of both sides. 
> > 
> >
> > You have to understand Bonita that lockfree has advantages and disadvantages, so since lock-free queue works best when the queue nearly always has entries, ... 
> 
> This can't be guaranteed since the producer can be scheduled away. 
> No one uses lock-free queues, they're simply silly.


I think you are not understanding, since you are trying to generalize more
and you are saying that it is not working, but it is not the right way ,
since you have to know how to fix the number of consumers and producers
so that it works. So when you are using lock-free queues you have to like
calculate more precisely like in realtime systems so that it be efficient.

And you have to know that when you fix correctly the number of consumers 
and producers so that to be efficient, this "efficient" is not just about the throughput 
of the lock-free queues, since i mean the even if you fix the number of consumers 
and producers and it gives less throughput than the blocking queues , it can be that you 
are wanting to benefit from some or all the characteristics of the being lock-free.

Thank you,
Amine Moulay Ramdane.









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


#7394

FromBonita Montero <Bonita.Montero@gmail.com>
Date2022-02-18 17:41 +0100
Message-ID<suoi8n$utn$1@dont-email.me>
In reply to#7393
Am 18.02.2022 um 16:58 schrieb Amine Moulay Ramdane:
> On Friday, February 18, 2022 at 1:31:31 AM UTC-5, Bonita Montero wrote:
>> Am 17.02.2022 um 22:28 schrieb Amine Moulay Ramdane:
>>> On Thursday, February 17, 2022 at 3:23:22 PM UTC-5, Bonita Montero wrote:
>>>> Am 17.02.2022 um 20:41 schrieb Amine Moulay Ramdane:
>>>>> On Thursday, February 17, 2022 at 2:27:30 PM UTC-5, Bonita Montero wrote:
>>>>>> Am 17.02.2022 um 20:02 schrieb Amine Moulay Ramdane:
>>>>>>> Hello,
>>>>>>>
>>>>>>>
>>>>>>> More of my philosophy about my new inventions and more..
>>>>>>>
>>>>>>> I am a white arab and i think i am smart since i have also invented many scalable algorithms..
>>>>>>>
>>>>>>>
>>>>>>> I think i am smart, and i say that x86 processor family features a fairly strict memory model that only allows the reorderings of loads before independent store operations, so i have just invented a fully Lockfree FIFO bounded queue and a fully Lockfree LIFO bounded stack that also run on x86 processor family and they are much more powerful than my following inventions:
>>>>>> Lock-free queues totally suck since they have to be polled.
>>>>>> The only lock-free structure that is useful is a lock-free stack
>>>>>> for pooing objects and handling back items to a thread like with
>>>>>> modern memory-allocators.
>>>>>
>>>>>
>>>>> Typically, polling a lock-free queue works best when the queue nearly always has entries, a blocking queue works best when the queue is nearly always empty.
>>>> Forget it - no one wants to poll a queue. Having limited
>>>> polling with spinning for a while is the best of both sides.
>>>
>>>
>>> You have to understand Bonita that lockfree has advantages and disadvantages, so since lock-free queue works best when the queue nearly always has entries, ...
>>
>> This can't be guaranteed since the producer can be scheduled away.
>> No one uses lock-free queues, they're simply silly.
> 
> 
> I think you are not understanding, since you are trying to generalize more
> and you are saying that it is not working, but it is not the right way ,
> since you have to know how to fix the number of consumers and producers
> so that it works. ..

The number of consumers and producers doesn't matter. If a producer
can be scheduled away a consumer would poll for a vers long time.

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


#7395

FromAmine Moulay Ramdane <aminer68@gmail.com>
Date2022-02-18 08:56 -0800
Message-ID<9480c8d2-c8fc-42ad-9972-4aca7e572672n@googlegroups.com>
In reply to#7394
On Friday, February 18, 2022 at 11:42:04 AM UTC-5, Bonita Montero wrote:
> Am 18.02.2022 um 16:58 schrieb Amine Moulay Ramdane: 
> > On Friday, February 18, 2022 at 1:31:31 AM UTC-5, Bonita Montero wrote: 
> >> Am 17.02.2022 um 22:28 schrieb Amine Moulay Ramdane: 
> >>> On Thursday, February 17, 2022 at 3:23:22 PM UTC-5, Bonita Montero wrote: 
> >>>> Am 17.02.2022 um 20:41 schrieb Amine Moulay Ramdane: 
> >>>>> On Thursday, February 17, 2022 at 2:27:30 PM UTC-5, Bonita Montero wrote: 
> >>>>>> Am 17.02.2022 um 20:02 schrieb Amine Moulay Ramdane: 
> >>>>>>> Hello, 
> >>>>>>> 
> >>>>>>> 
> >>>>>>> More of my philosophy about my new inventions and more.. 
> >>>>>>> 
> >>>>>>> I am a white arab and i think i am smart since i have also invented many scalable algorithms.. 
> >>>>>>> 
> >>>>>>> 
> >>>>>>> I think i am smart, and i say that x86 processor family features a fairly strict memory model that only allows the reorderings of loads before independent store operations, so i have just invented a fully Lockfree FIFO bounded queue and a fully Lockfree LIFO bounded stack that also run on x86 processor family and they are much more powerful than my following inventions: 
> >>>>>> Lock-free queues totally suck since they have to be polled. 
> >>>>>> The only lock-free structure that is useful is a lock-free stack 
> >>>>>> for pooing objects and handling back items to a thread like with 
> >>>>>> modern memory-allocators. 
> >>>>> 
> >>>>> 
> >>>>> Typically, polling a lock-free queue works best when the queue nearly always has entries, a blocking queue works best when the queue is nearly always empty. 
> >>>> Forget it - no one wants to poll a queue. Having limited 
> >>>> polling with spinning for a while is the best of both sides. 
> >>> 
> >>> 
> >>> You have to understand Bonita that lockfree has advantages and disadvantages, so since lock-free queue works best when the queue nearly always has entries, ... 
> >> 
> >> This can't be guaranteed since the producer can be scheduled away. 
> >> No one uses lock-free queues, they're simply silly. 
> > 
> > 
> > I think you are not understanding, since you are trying to generalize more 
> > and you are saying that it is not working, but it is not the right way , 
> > since you have to know how to fix the number of consumers and producers
> > so that it works. .. 
> 
> The number of consumers and producers doesn't matter. If a producer 
> can be scheduled away a consumer would poll for a vers long time.

I don't agree with you, since a non-blocking algorithm 
is lock-free if there is guaranteed system-wide progress,
so if you fix correctly the number of consumers and producers, 
and you have many more producers than one producer, so if 
a producer is scheduled away , another producer will do the job rapidly,
since system-wide progress is guaranteed by the lock-free algorithm,
so i advice you to read more about what is lock-free algorithms.

Thank you,
Amine Moulay Ramdane. 

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


#7396

FromAmine Moulay Ramdane <aminer68@gmail.com>
Date2022-02-18 12:50 -0800
Message-ID<31aecb13-df09-4d6c-806d-bb1514ded645n@googlegroups.com>
In reply to#7394
On Friday, February 18, 2022 at 11:42:04 AM UTC-5, Bonita Montero wrote:
> Am 18.02.2022 um 16:58 schrieb Amine Moulay Ramdane: 
> > On Friday, February 18, 2022 at 1:31:31 AM UTC-5, Bonita Montero wrote: 
> >> Am 17.02.2022 um 22:28 schrieb Amine Moulay Ramdane: 
> >>> On Thursday, February 17, 2022 at 3:23:22 PM UTC-5, Bonita Montero wrote: 
> >>>> Am 17.02.2022 um 20:41 schrieb Amine Moulay Ramdane: 
> >>>>> On Thursday, February 17, 2022 at 2:27:30 PM UTC-5, Bonita Montero wrote: 
> >>>>>> Am 17.02.2022 um 20:02 schrieb Amine Moulay Ramdane: 
> >>>>>>> Hello, 
> >>>>>>> 
> >>>>>>> 
> >>>>>>> More of my philosophy about my new inventions and more.. 
> >>>>>>> 
> >>>>>>> I am a white arab and i think i am smart since i have also invented many scalable algorithms.. 
> >>>>>>> 
> >>>>>>> 
> >>>>>>> I think i am smart, and i say that x86 processor family features a fairly strict memory model that only allows the reorderings of loads before independent store operations, so i have just invented a fully Lockfree FIFO bounded queue and a fully Lockfree LIFO bounded stack that also run on x86 processor family and they are much more powerful than my following inventions: 
> >>>>>> Lock-free queues totally suck since they have to be polled. 
> >>>>>> The only lock-free structure that is useful is a lock-free stack 
> >>>>>> for pooing objects and handling back items to a thread like with 
> >>>>>> modern memory-allocators. 
> >>>>> 
> >>>>> 
> >>>>> Typically, polling a lock-free queue works best when the queue nearly always has entries, a blocking queue works best when the queue is nearly always empty. 
> >>>> Forget it - no one wants to poll a queue. Having limited 
> >>>> polling with spinning for a while is the best of both sides. 
> >>> 
> >>> 
> >>> You have to understand Bonita that lockfree has advantages and disadvantages, so since lock-free queue works best when the queue nearly always has entries, ... 
> >> 
> >> This can't be guaranteed since the producer can be scheduled away. 
> >> No one uses lock-free queues, they're simply silly. 
> > 
> > 
> > I think you are not understanding, since you are trying to generalize more 
> > and you are saying that it is not working, but it is not the right way , 
> > since you have to know how to fix the number of consumers and producers
> > so that it works. .. 
> 
> The number of consumers and producers doesn't matter. If a producer 
> can be scheduled away a consumer would poll for a vers long time.

I think you are idiotic, since you are saying that you have 
to use like an hybrid way of using blocking and lock-free, but it is an idiotic
way of doing since you will lose some important advantages of lock-free , 
so it is why i am not idiotically throwing away lock-free queues as you are 
doing it, since i still want to take advantage of the characteristics of the 
being lock-free, so you have to read my following other extended answer 
so that you notice that operating systems schedulers such as Windows 
and Linux are giving a big enough time slice that allows the next producer 
to successfully put the item in the lock-free queue. So read my following 
extended thoughts about it:

I say that eventhough the producer is scheduled away , 
you have to think about the big enough time slice that allows 
the next producer to successfully put the item in the lock-free queue, 
and as we know that each software thread gets a short turn, 
called a time slice, to run on a hardware thread. When the time slice 
runs out, the scheduler suspends the thread and allows the next 
thread waiting its turn to run on the hardware thread. And time slicing 
ensures that all software threads make some progress. And as we know 
that there is the overhead of saving the register state of a thread when 
suspending it, and restoring the state when resuming it. 
You might be surprised how much state there is on modern processors. 
However, schedulers typically allocate big enough time slices so that 
the save/restore overheads are insignificant, so this obvious overhead 
is in fact not much of a concern.

So you are like idiotic Bonita Montero, since it is as you are comparing 
the locks that use CPU-intensive spinning and mutexes that don't use it, 
so we can use CPU-intensive spinning if the critical section is small,
so it is by logical analogy the same as lock-free algorithms, since 
lock-free algorithms need from you to control correctly the situation or 
the context, i mean that you have to know how to tune the number of 
threads of the system including the consumers and producers of the 
lock-free queues so that to be able to benefit from advantages of the 
being lock-free.


Thank you,
Amine Moulay Ramdane. 



   

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


#7385

FromAmine Moulay Ramdane <aminer68@gmail.com>
Date2022-02-17 11:44 -0800
Message-ID<fa2a3a3a-9f3f-48cd-a9be-74b88edf976fn@googlegroups.com>
In reply to#7383
On Thursday, February 17, 2022 at 2:27:30 PM UTC-5, Bonita Montero wrote:
> Am 17.02.2022 um 20:02 schrieb Amine Moulay Ramdane: 
> > Hello, 
> > 
> > 
> > More of my philosophy about my new inventions and more.. 
> > 
> > I am a white arab and i think i am smart since i have also invented many scalable algorithms.. 
> > 
> > 
> > I think i am smart, and i say that x86 processor family features a fairly strict memory model that only allows the reorderings of loads before independent store operations, so i have just invented a fully Lockfree FIFO bounded queue and a fully Lockfree LIFO bounded stack that also run on x86 processor family and they are much more powerful than my following inventions:
> Lock-free queues totally suck since they have to be polled. 
> The only lock-free structure that is useful is a lock-free stack 
> for pooing objects and handling back items to a thread like with 
> modern memory-allocators.


On Thursday, February 17, 2022 at 2:27:30 PM UTC-5, Bonita Montero wrote:
> Am 17.02.2022 um 20:02 schrieb Amine Moulay Ramdane: 
>> Hello, 
>>
>>
>> More of my philosophy about my new inventions and more.. 
>>
>> I am a white arab and i think i am smart since i have also invented many scalable algorithms.. 
>>
>>
>> I think i am smart, and i say that x86 processor family features a fairly strict memory model that only allows the reorderings of loads before independent store operations, so i have just invented a fully Lockfree FIFO bounded queue and a fully Lockfree LIFO bounded stack that also run on x86 processor family and they are much more powerful than my following inventions:
> Lock-free queues totally suck since they have to be polled. 
> The only lock-free structure that is useful is a lock-free stack 
> for pooing objects and handling back items to a thread like with 
> modern memory-allocators.

Hello,


Typically, polling a lock-free queue works best when the queue nearly always has entries, a blocking queue works best when the queue is nearly always empty.

The downside of blocking queues is latency, typically of the order of 2-20 uS, due to kernel signaling. This can be mitigated by designing the system so that the work done by the consumer threads on each queued item takes much longer than this interval.

The downside of non-blocking queues is the waste of CPU and memory bandwidth while polling an empty queue. This can be mitigated by designing the system so that the queue is rarely empty.

A non-blocking queue is a very bad idea on single-CPU systems.



Thank you,
Amine Moulay Ramdane.

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


#7386

FromAmine Moulay Ramdane <aminer68@gmail.com>
Date2022-02-17 11:49 -0800
Message-ID<ec7c213b-f4e2-4bfd-8df6-c935496c4e0cn@googlegroups.com>
In reply to#7385
On Thursday, February 17, 2022 at 2:44:59 PM UTC-5, Amine Moulay Ramdane wrote:
> On Thursday, February 17, 2022 at 2:27:30 PM UTC-5, Bonita Montero wrote:
> > Am 17.02.2022 um 20:02 schrieb Amine Moulay Ramdane: 
> > > Hello, 
> > > 
> > > 
> > > More of my philosophy about my new inventions and more.. 
> > > 
> > > I am a white arab and i think i am smart since i have also invented many scalable algorithms.. 
> > > 
> > > 
> > > I think i am smart, and i say that x86 processor family features a fairly strict memory model that only allows the reorderings of loads before independent store operations, so i have just invented a fully Lockfree FIFO bounded queue and a fully Lockfree LIFO bounded stack that also run on x86 processor family and they are much more powerful than my following inventions: 
> > Lock-free queues totally suck since they have to be polled. 
> > The only lock-free structure that is useful is a lock-free stack 
> > for pooing objects and handling back items to a thread like with 
> > modern memory-allocators.
> On Thursday, February 17, 2022 at 2:27:30 PM UTC-5, Bonita Montero wrote:
> > Am 17.02.2022 um 20:02 schrieb Amine Moulay Ramdane: 
> >> Hello, 
> >> 
> >> 
> >> More of my philosophy about my new inventions and more.. 
> >> 
> >> I am a white arab and i think i am smart since i have also invented many scalable algorithms.. 
> >> 
> >> 
> >> I think i am smart, and i say that x86 processor family features a fairly strict memory model that only allows the reorderings of loads before independent store operations, so i have just invented a fully Lockfree FIFO bounded queue and a fully Lockfree LIFO bounded stack that also run on x86 processor family and they are much more powerful than my following inventions: 
> > Lock-free queues totally suck since they have to be polled. 
> > The only lock-free structure that is useful is a lock-free stack 
> > for pooing objects and handling back items to a thread like with 
> > modern memory-allocators.
> Hello,
> Typically, polling a lock-free queue works best when the queue nearly always has entries, a blocking queue works best when the queue is nearly always empty. 
> 
> The downside of blocking queues is latency, typically of the order of 2-20 uS, due to kernel signaling. This can be mitigated by designing the system so that the work done by the consumer threads on each queued item takes much longer than this interval. 
> 
> The downside of non-blocking queues is the waste of CPU and memory bandwidth while polling an empty queue. This can be mitigated by designing the system so that the queue is rarely empty.
> A non-blocking queue is a very bad idea on single-CPU systems.
> Thank you, 
> Amine Moulay Ramdane.

Hello,


Here is more of my precision:

Typically, polling a lock-free queue works best when the queue nearly always has entries, a blocking queue works best when the queue is nearly always empty.

A downside of blocking queues is latency, typically of the order of 2-20 uS, due to kernel signaling. This can be mitigated by designing the system so that the work done by the consumer threads on each queued item takes much longer than this interval.

The downside of non-blocking queues is the waste of CPU and memory bandwidth while polling an empty queue. This can be mitigated by designing the system so that the queue is rarely empty.


Thank you,
Amine Moulay Ramdane.

[toc] | [prev] | [standalone]


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


csiph-web