Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming.threads > #7382 > unrolled thread
| Started by | Amine Moulay Ramdane <aminer68@gmail.com> |
|---|---|
| First post | 2022-02-17 11:02 -0800 |
| Last post | 2022-02-17 11:49 -0800 |
| Articles | 12 — 2 participants |
Back to article view | Back to comp.programming.threads
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
| From | Amine Moulay Ramdane <aminer68@gmail.com> |
|---|---|
| Date | 2022-02-17 11:02 -0800 |
| Subject | More 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]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-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]
| From | Amine Moulay Ramdane <aminer68@gmail.com> |
|---|---|
| Date | 2022-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]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-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]
| From | Amine Moulay Ramdane <aminer68@gmail.com> |
|---|---|
| Date | 2022-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]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-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]
| From | Amine Moulay Ramdane <aminer68@gmail.com> |
|---|---|
| Date | 2022-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]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-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]
| From | Amine Moulay Ramdane <aminer68@gmail.com> |
|---|---|
| Date | 2022-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]
| From | Amine Moulay Ramdane <aminer68@gmail.com> |
|---|---|
| Date | 2022-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]
| From | Amine Moulay Ramdane <aminer68@gmail.com> |
|---|---|
| Date | 2022-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]
| From | Amine Moulay Ramdane <aminer68@gmail.com> |
|---|---|
| Date | 2022-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