About PhDs in computer science..

[computer45]

Hello...

Read this:

About PhDs in computer science..

Look at This PhD paper of a Scalable Concurrent Priority Queue
Algorithms:

http://people.csail.mit.edu/shanir/publications/SZ-priority.pdf

This queue is "not" bound, and i think it uses a mechanism such
as an elimination array..

And look at this one of a PhD paper called: Using Elimination to
Implement Scalable and Lock-Free FIFO Queues :

http://www.cs.tau.ac.il/~shanir/nir-pubs-web/Papers/SPAA2005.pdf

I think it is not good or perfect because it uses an elimination
array, so when there is no contention or no elimination it doesn't
scale.

But my fully scalable FIFO queue that i have invented has completely
"revolutionized" computer science, because it is the "perfect"
scalable FIFO queue that is fully scalable even if there is no
contention, I have implemented three versions of my scalable FIFO queue,
here they are:

1- A fully scalable FIFO queue that is bound and that is not blocking on
the producer side and that is blocking on the consumer side.

2- A fully scalable FIFO queue that is unbound and that is not blocking
on the producer side and that is blocking on the consumer side.

3- A fully scalable FIFO queue that is bound and that is blocking on the
producer side and that is blocking on the consumer side.


And i have also invented a fully scalable Threadpool.


I will sell them to Embarcadero and to other software companies such as
Microsoft and Google etc.


Also i will sell them to CAE here, because they need to scale more to
many many cores, read here to know about this company:

https://www.cray.com/blog/extreme-scaling-in-cae-applications/

Here is CAE company:

http://www.cae.com/


And i have also invented a fully scalable reference counting with
efficient support for weak references, here it is:

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


Thank you,
Amine Moulay Ramdane.

[Mr Flibble]

On 22/03/2018 20:47, computer45 wrote:

>
> But my fully scalable FIFO queue that i have invented has completely
> "revolutionized" computer science, because it is the "perfect"
> scalable FIFO queue that is fully scalable even if there is no
> contention, I have implemented three versions of my scalable FIFO queue,
> here they are:

You are quite delusional you know. There is nothing remarkable about
your FIFO queue; FIFO queues have been around for decades.

/Flibble

--
"Suppose it’s all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I’d say, bone cancer in children? What’s that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It’s not right, it’s utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates
a world that is so full of injustice and pain. That’s what I would say."

[computer45]

On 3/22/2018 5:17 PM, Mr Flibble wrote:
> On 22/03/2018 20:47, computer45 wrote:
>
>>
>> But my fully scalable FIFO queue that i have invented has completely
>> "revolutionized" computer science, because it is the "perfect"
>> scalable FIFO queue that is fully scalable even if there is no
>> contention, I have implemented three versions of my scalable FIFO
>> queue, here they are:
>
> You are quite delusional you know.  There is nothing remarkable about
> your FIFO queue; FIFO queues have been around for decades.
>
> /Flibble
>

You don't understand , it is a scalable FIFO queue, its throughput will
"scale" more and more when you add more cores and more threads.

[Mr Flibble]

Yes I do understand. Lock-free queues have been around for some time:
you are not the first to "invent" one.

[computer45]

On 3/22/2018 5:44 PM, Mr Flibble wrote:
> On 22/03/2018 21:34, computer45 wrote:
>> On 3/22/2018 5:17 PM, Mr Flibble wrote:
>>> On 22/03/2018 20:47, computer45 wrote:
>>>
>>>>
>>>> But my fully scalable FIFO queue that i have invented has completely
>>>> "revolutionized" computer science, because it is the "perfect"
>>>> scalable FIFO queue that is fully scalable even if there is no
>>>> contention, I have implemented three versions of my scalable FIFO
>>>> queue, here they are:
>>>
>>> You are quite delusional you know.  There is nothing remarkable about
>>> your FIFO queue; FIFO queues have been around for decades.
>>>
>>> /Flibble
>>>
>>
>>
>> You don't understand , it is a scalable FIFO queue, its throughput will
>> "scale" more and more when you add more cores and more threads.
>
> Yes I do understand.  Lock-free queues have been around for some time:
> you are not the first to "invent" one.
>
> /Flibble
>

You "still" don't understand , Lockfree FIFO queues are not "scalable",
mine "is" scalable , its throughput scales "linearly" with more cores
and more threads. And it can be easily configured to be waitfree or
lockfree or blocking.

[computer45]

On 3/22/2018 5:44 PM, Mr Flibble wrote:
> On 22/03/2018 21:34, computer45 wrote:
>> On 3/22/2018 5:17 PM, Mr Flibble wrote:
>>> On 22/03/2018 20:47, computer45 wrote:
>>>
>>>>
>>>> But my fully scalable FIFO queue that i have invented has completely
>>>> "revolutionized" computer science, because it is the "perfect"
>>>> scalable FIFO queue that is fully scalable even if there is no
>>>> contention, I have implemented three versions of my scalable FIFO
>>>> queue, here they are:
>>>
>>> You are quite delusional you know.  There is nothing remarkable about
>>> your FIFO queue; FIFO queues have been around for decades.
>>>
>>> /Flibble
>>>
>>
>>
>> You don't understand , it is a scalable FIFO queue, its throughput will
>> "scale" more and more when you add more cores and more threads.
>
> Yes I do understand.  Lock-free queues have been around for some time:
> you are not the first to "invent" one.
>
> /Flibble
>

More precision..

You "still" don't understand , Lockfree queues or waitfree FIFO queue
or blocking FIFO queues are not "scalable", mine "is" scalable , its

throughput scales "linearly" with more cores and more threads. And it
can be easily configured to be waitfree or lockfree or blocking.

[Mr Flibble]

Yes I do understand. Lock-free FIFO queues are scalable; you haven't
invented anything.

[computer45]

You "still" don't understand, i know more than you on this subject,
Lockfree queues use an "atomic" compare_and_exchange that is like
a "lock" and it incurs "contention", so Lockfree queues are "not"
scalable, waitfree FIFO queues are not scalable either and blocking FIFO
queues are not scalable either. You seem to not understand this subject.

Mine "is" scalable , its throughput scales "linearly" with more cores

and more threads. And it can be easily configured to be waitfree or
lockfree or blocking.

[Chris M. Thomasson]

Distributed wait-free queues can be highly scalable. It depends on how
you organize them. A clever network of single consumer and single
producer wait-free queues does scale.

[computer45]

In your configuration of single consumer and single
producer wait-free queues , you have to organize them in a
distributed manner, but mine doesn't need that, you have
to just plug mine and it will work easily and it will be scalable and
it can be easily configured to be lockfree or waitfree

or blocking.



Thank you,
Amine Moulay Ramdane.

You have to organize them in a distributed

[Chris M. Thomasson]

The actual queue wrt single producer, single consumer (SPSC) can be
built without using any atomic RMW's or heavy memory barriers. A network
of said queues is pretty nice. Also, we can create a network using
different types of queues. Say, a layer of single consumer multi
producers queues (MPSC) along with per-thread SPSC. It does work.

[Chris M. Thomasson]

But, yours has to be distributed "under the hood", no? Think of
distributed bakery algorithms. Think of each thread having a queue that
is registered in a database.

[computer45]

I understand you, but it is not an "ideal" world , we have to provide
with mine also, because it is very easy to work with.


Thank you,
Amine Moulay Ramdane/

[computer45]

Yes, Mine is distributed under the hood", but its advantage
also is that it is very easy to work with, no configuration
as the distributed single producer single consumer queues.

[Chris M. Thomasson]

Can it auto adapt to a particular problem? I have a generic setup, but
it can be "better" to see if we can "configure" the queues to best suit
the program logic at hand. In other words, the custom setup tends to
outperform the generic setup, in a sense. Sometimes the program logic is
not really "compatible" with distributed queue setup.

[computer45]

On 3/22/2018 6:40 PM, Chris M. Thomasson wrote:
>
> Can it auto adapt to a particular problem?

You are not understand mine, it is not distributed as the
single consumer and single producer queue, mine can adapt to all
problems, it is like a regular FIFO queue, just plug it and it will work
like a charm and it will be scalable, and it can easily be configured to
be lockfree or waifree or blocking.

[computer45]

Read again, i correct

You are not understanding mine, it is not distributed as the
single consumer and single producer queues, mine can adapt to all

problems, it is like a regular FIFO queue, just plug it and it will work

like a charm and it will be scalable, and it can easily be configured to
be lockfree or waifree or blocking.

[Chris M. Thomasson]

Also, keep in mind that my FIFO bakery queue can be distributed, as in
use more than one of itself at a time, and rather easily made to work
with any mode of operation therein wrt, say:

Single-Producer Single-Consumer (SPSC)
Single-Producer Multi-Consumer (SPMC)
Multi-Producer Single-Consumer (MPSC)
Multi-Producer Multi-Consumer (MPMC)

The SPSC mode is the best simply because it eliminates the need for any
expensive atomic RMW's.

Fwiw, for anybody else reading this, refer to the following link for the
MPMC mode of my bakery queue:

https://groups.google.com/d/topic/lock-free/acjQ3-89abE/discussion
(read all if interested...)

All of this can be implemented in pure C++11. Well, of course C++11 does
not have support for asymmetric sync... That is a limitation because it
means we have to use OS and/or CPU specific features. Think of:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms683148(v=vs.85).aspx

Btw, this can be a very handy function... :^)

[Chris M. Thomasson]

First you said it is distributed under the hood. Now you say it is not
distributed as the single consumer and single producer queues. You are
losing me here. Please clarify. I have a generic setup that is
plug-and-play. However, it is not as good as a custom setup. How are you
getting around that?

[computer45]

I want to say that mine is easy to work with, no configuration,
because it uses "scalable" counting networks and it is scalable.

[Chris M. Thomasson]

No caveats?

[computer45]

On 3/22/2018 7:00 PM, Chris M. Thomasson wrote:
> No caveats?

Right, no caveats as you are describing on the distributed single
consumer single producer queues. This is why i want to sell it.


Thank you,
Amine Moulay Razmdane.

[Chris M. Thomasson]

On 3/22/2018 4:04 PM, computer45 wrote:
> On 3/22/2018 7:00 PM, Chris M. Thomasson wrote:
>> No caveats?
>
> Right, no caveats as you are describing on the distributed single
> consumer single producer queues. This is why i want to sell it.

Interesting claim. I need to study your algorithm some more. Btw, why
not go ahead and try to implement it in C++11?

[computer45]

I have invented this scalable algorithm, and i have implement it ,
but i want to sell it to software companies like Microsoft or Google
etc.

Please tell me some more about the caveats of the distributed single
consumer and single producer queues, what are all the disadvantages of
the distributed single consumer and single producer queues ?

[Chris M. Thomasson]

Strict FIFO order can be broken.

[computer45]

I understand. But my scalable FIFO queue doesn't have this problem
because it is "FIFO" and it is "scalable" and it can be configured
easily to be lockfree or waitfree or blocking. So i think my scalable
FIFO queue is useful and i think i will try to sell it, because we have
to provide with mine, since it is not an "ideal" world.

[computer45]

Look also at FastFlow, they say this:

---
FastFlow queues

Building a streaming network on top of SPSC queues means potentially
using many queues, even if they are automatically generated and
assembled in MPMC queues.

How are MPMC queues realized?

Multiple-Producer-Multiple-Consumer (MPMC) queues are realized using one
SPSC queue per producer and one SPSC queue per consumer. These queues
are put together using an arbiter thread in a fully lock-free and
fence-free fashion (no CAS at all). SPSC queues are enriched with
additional methods aimed at improving cache locality and throughput,
such as multi-push. In addition, FastFlow provides several variants of
classic lock-free queues (using CAS operations) such as the
Michael&Scott queue, which leverage on deferred reclamation and memory
alignment provided by FastFlow allocators.
---




So as you have noticed they are not saying that the MPMC queue of
FastFlow, from the distributed network of single producer and single
producer queues, is "FIFO".

[computer45]

Read again, i correct:

Look also at FastFlow, they say this:

---
FastFlow queues

Building a streaming network on top of SPSC queues means potentially
using many queues, even if they are automatically generated and
assembled in MPMC queues.

How are MPMC queues realized?

Multiple-Producer-Multiple-Consumer (MPMC) queues are realized using one
SPSC queue per producer and one SPSC queue per consumer. These queues
are put together using an arbiter thread in a fully lock-free and
fence-free fashion (no CAS at all). SPSC queues are enriched with
additional methods aimed at improving cache locality and throughput,
such as multi-push. In addition, FastFlow provides several variants of
classic lock-free queues (using CAS operations) such as the
Michael&Scott queue, which leverage on deferred reclamation and memory
alignment provided by FastFlow allocators.
---

Read more here:

http://calvados.di.unipi.it/dokuwiki/doku.php/ffnamespace:faq

So as you have noticed they are not saying that the MPMC queue of
FastFlow, from the distributed network of single producer and single
producer queues, is "FIFO".

[computer45]

Read again on FastFlow there is another disadvantage:

"Multiple-Producer-Multiple-Consumer (MPMC) queues are realized using
one SPSC queue per producer and one SPSC queue per consumer."

Read more here:

http://calvados.di.unipi.it/dokuwiki/doku.php/ffnamespace:faq

This is stupid, because how can you scale dynamically this MPMC queue ?
it can not do that, but mine can do that.

Other than that Strict FIFO order can be broken on the distributed
network of SPSC queues.


But my scalable FIFO queue doesn't have those problems,

So i think my scalable FIFO queue is useful and i think i will try to
sell it, because we have to provide with mine, since it is not an
"ideal" world.

[computer45]

Read again on FastFlow there is another disadvantage:


"Multiple-Producer-Multiple-Consumer (MPMC) queues are realized using
one SPSC queue per producer and one SPSC queue per consumer."


Read more here:

http://calvados.di.unipi.it/dokuwiki/doku.php/ffnamespace:faq


This is stupid, because how can you scale dynamically this MPMC queue ?
it can not do that, but mine can do that.

Other than that Strict FIFO order can be broken on the distributed
network of SPSC queues.


But my scalable FIFO queue doesn't have those problems,
So i think my scalable FIFO queue is useful and i think i will try to
sell it, because we have to provide with mine, since it is not an
"ideal" world.

[Chris M. Thomasson]

That is a pretty bad design wrt using Michael&Scott like CAS-based
queues, or any queue that needs deferred reclamation. Not good.

> ---
>
>
>
>
> So as you have noticed they are not saying that the MPMC queue of
> FastFlow, from the distributed network of single producer and single
> producer queues, is "FIFO".

It really can't be.

[Mr Flibble]

Yes I do understand. Intel published a paper nearly ten years ago about
unbounded SPSC queue utilising cache line padding. You haven't invented
anything.

/Flibble

[computer45]

You are again talking like garbage, and you are like throwing garbage
here, because what have to do an SPSC with my scalable MPMC FIFO Queue ?



Thank you,
Amine Moulay Ramdane,.

[Mr Flibble]

You are the one talking garbage constantly repeating yourself claiming to
invent things that others have before you and duplicating posts to this NG
annoying everyone.

/Flibble

[computer45]

You are escaping the "subject", you have just come with an SPSC from
Intel in your post before, but we are not talking about SPSC queues, we
are talking about MPMC queues, my queue is a scalable MPMC FIFO queue,
this is why you are talking garbage.

[computer45]

I think you are not thinking correctly Mr Flibble, and this is also
garbage, because you have to compare apples with apples , not oranges
with apples, you are speaking about SPSC , but SPSC is not MPMC
and my scalable FIFO queue is MPMC, other than that if we organize
your SPSCs into a mesh or network of SPSCs queues to make a scalable
MPMC , here again we have to compare apples with apples and we have
to compare correctly, for example what are the advantages and
disadvantages of mesh or network of SPSCs queues to make a scalable
MPMC , and to compare it with my scalable FIFO queue, first you will
notice that it is more "lightweight", because it doesn't use any atomic
RMW's or heavy memory barriers , but the disadvantage is that the Strict
FIFO order can be broken, but my scalable FIFO queue is "FIFO" , but we
can also make mine without atomic RMW's or heavy memory barriers, so i
think my scalable FIFO queue is still useful and i think it is an invention.

[computer45]

We have to be smart, i think if we compare mesh or network of SPSCs
queues to make a scalable MPMC queue with my scalable MPMC FIFO queue,
it is as we compare oranges with apples, because strict FIFO order
can be broken in the mesh or network of SPSCs queues to make a scalable
MPMC queue. So we have to not make the comparison.

So we have to compare like apples with apples, so we have to compare
with other scalable FIFO queues, here they are:

Look at This PhD paper of a Scalable Concurrent Priority Queue
Algorithms:

http://people.csail.mit.edu/shanir/publications/SZ-priority.pdf

This queue is "not" bound, and i think it uses a mechanism such
as an elimination array..

And look at this one of a PhD paper called: Using Elimination to
Implement Scalable and Lock-Free FIFO Queues :

http://www.cs.tau.ac.il/~shanir/nir-pubs-web/Papers/SPAA2005.pdf

I think it is not good or perfect because it uses an elimination
array, so when there is no contention or no elimination it doesn't
scale.

But my fully scalable FIFO queue that i have invented has completely
"revolutionized" computer science, because it is the "perfect"
scalable FIFO queue that is fully scalable even if there is no
contention, I have implemented three versions of my scalable FIFO queue,
here they are:

1- A fully scalable FIFO queue that is bound and that is not blocking on
the producer side and that is blocking on the consumer side.

2- A fully scalable FIFO queue that is unbound and that is not blocking
on the producer side and that is blocking on the consumer side.

3- A fully scalable FIFO queue that is bound and that is blocking on the
producer side and that is blocking on the consumer side.


And i have also invented a fully scalable Threadpool.


I will sell them to Embarcadero and to other software companies such as
Microsoft and Google etc.


Also i will sell them to CAE here, because they need to scale more to
many many cores, read here to know about this company:

https://www.cray.com/blog/extreme-scaling-in-cae-applications/

Here is CAE company:

http://www.cae.com/


And i have also invented a fully scalable reference counting with
efficient support for weak references, here it is:

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

[Chris M. Thomasson]

The distributed part is okay, but the CAS based queue deferred crap can
be dropped completely.

[Bo Persson]

So it might improve our understanding if you included a link to *your*
thesis, where all this is thoroughly explained.



Bo Persson

[Mr Flibble]

a) you have yet to show that you have invented anything original;
b) you are quite delusional suffering from delusions of grandeur.

/Flibble

--
"Suppose it’s all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I’d say, bone cancer in children? What’s that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It’s not right, it’s utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates
a world that is so full of injustice and pain. That’s what I would say."

[Chris M. Thomasson]

Where is the code for your:

CountingNetworks_UInt32_32-bit_n1.dll
CountingNetworks_UInt32_64-bit_n1.dll

?

[computer45]

I have also modified and optimized the scalable counting network
algorithm, this is why i am not giving the source code, and i think the
DLLs are working correctly, because i have debugged and tested them a lot.

Have you another question to ask ?

[computer45]

Read again:

I have also enhanced and optimized the scalable counting network

algorithm, this is why i am not giving the source code, and i think the
DLLs are working correctly, because i have debugged and tested them a lot.

Have you another question to ask ?

[Chris M. Thomasson]

If you are not going to release the source code, then how can we inspect
your work? Btw, you did mention the phrase "enhanced and optimized".
This makes me want to think that you got the original scalable counting
network from somewhere else? If I am correct, where did you get it from
in the first place? Thanks.

[Chris M. Thomasson]

I tried to take a look, however, his code is secret.

[computer45]

You will find it in the book: "The art of multiprocessor programming"

Here it is:

https://www.amazon.ca/Art-Multiprocessor-Programming-Revised-Reprint/dp/0123973376

But i have enhance it and optimized more the algorithm.

[computer45]

Read gain, i correct:

You will find it in the book: "The art of multiprocessor programming"

Here it is:

https://www.amazon.ca/Art-Multiprocessor-Programming-Revised-Reprint/dp/0123973376

But i have enhanced and optimized more the algorithm.

[computer45]

The DLLs are just the counting network algorithm inplementation,
You will find the algorithm implementation it in the book: "The art of

multiprocessor programming"

Here it is:

https://www.amazon.ca/Art-Multiprocessor-Programming-Revised-Reprint/dp/0123973376

But i have enhanced and optimized more the algorithm.

Now my scalable reference counting algorithm implementation is inside
the zip file and named AMInterfacedObject.pas , you can compile
the demo file called test.pas or the demo file called example.dpr with
the following version of Freepascal:
ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/

it is FPC version 3.1.1, it must be 3.1.0 or up to compile
my project or you can use also Delphi XE and up or Delphi tokyo.

[Dan Cross]

In article <p966vc$jks$1...@dont-email.me>,
computer45 <compu...@cyber.com> wrote:
>[...]

>
>Now my scalable reference counting algorithm implementation is inside
>the zip file and named AMInterfacedObject.pas , you can compile
>the demo file called test.pas or the demo file called example.dpr with
>the following version of Freepascal:
>ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/
>
>it is FPC version 3.1.1, it must be 3.1.0 or up to compile
>my project or you can use also Delphi XE and up or Delphi tokyo.

I know better than to engage with a known troll, but....

Why is was this posted to comp.lang.c++ if it's about
some random algorithm implemented in Pascal?

- Dan C.

[Chris M. Thomasson]

Okay. Fwiw, I think Maurice has a brother named Greg:

https://www.linkedin.com/in/gregherlihy

I have conversed with him in the past over on comp.programming.threads

> But i have enhance it and optimized more the algorithm.

That's fine. Can you explain how you enhanced it?

[Chris M. Thomasson]

Fwiw, here is where Greg mentioned his brother:

https://groups.google.com/forum/#!original/comp.programming.threads/xQsUhQwPoOU/v9She5qqpA4J

[computer45]

Other than the strict FIFO order that can be broken, here is another
problem with the distributed network of SPSC queues, here it is:


--

5. finally, SPSC may not be a good point for massive ITC(inter-thread
communication):.

Because the space complexity goes in O(N^2), N is the number of threads.
It is not rare to see a server with 1k or 2k hardware threads. And "many
core" is the final destination of CPU from current sight.

---


Read all the following webpage and the responses to it to understand:

https://www.infoq.com/articles/High-Performance-Java-Inter-Thread-Communications



So then my scalable FIFO queue algorithm and its implementation is still
useful.

[computer45]

Read again, i correct:

Other than the strict FIFO order that can be broken, here is another
problem with the distributed network of SPSC queues, here it is:


--

5. finally, SPSC may not be a good point for massive ITC(inter-thread

communications):.

Because the space complexity goes in O(N^2), N is the number of threads.
It is not rare to see a server with 1k or 2k hardware threads. And "many
core" is the final destination of CPU from current sight.

---


Read all the following webpage and the responses to it to understand:

https://www.infoq.com/articles/High-Performance-Java-Inter-Thread-Communications



So then my scalable FIFO queue algorithm and its implementation is still
useful.

[Chris M. Thomasson]

My scheme uses layers of all the queue types. Imvvho, it is good to have
at least a MPSC queue on each thread. It allows multiple threads to send
messages to a "target" single thread. Btw, check this out:

https://groups.google.com/d/msg/comp.lang.c++/V0s__czQwa0/DgobuK9xAwAJ

It is not bounded, uses CAS for the push (arg!), but it does get around
having to use any deferred reclamation! The pop function retrieves all
the nodes at once using a single atomic swap. Think of multiplexing
these things.

Afaict, and imvho, fractals are abundant wrt all the different queue
types. Also, for each queue type we have the bounded or unbounded
qualifier, there is quite a bit of diversity. Think of a high level view
where we can only see MPMC queues, say we have mediocre eyesight for the
moment... We zoom in, and find out that they are actually comprised of
different types of queues that in and of themselves, do not offer MPMC.

> Because the space complexity goes in O(N^2), N is the number of threads.
> It is not rare to see a server with 1k or 2k hardware threads. And "many
> core" is the final destination of CPU from current sight.
>
> ---
>
>
> Read all the following webpage and the responses to it to understand:
>
> https://www.infoq.com/articles/High-Performance-Java-Inter-Thread-Communications

Will do.

> So then my scalable FIFO queue algorithm and its implementation is still
> useful.

I am not saying it is not useful. I just want to see your improvements,
in code. For some reason I like reading code more than a paper. ;^)

Btw, have you filed for a patent?

My advise to you... Go ahead and try to implement your work in C++11.
This group can help you out along the way. The more languages you can
implement your work in, the better... Fwiw, I think I remember a long
time ago when you used some of my assembly code in AppCore:

http://webpages.charter.net/appcore

Fwiw, here is a little JavaScript vector field plotter I made:

http://webpages.charter.net/appcore/fractal/field

Actually, this can be used to map out a network...

[Chris M. Thomasson]

[...]

It is MPMC in nature, and to get FIFO one can reverse the LIFO node list
returned from pop. These are fun to distribute.

[computer45]

Read again about network of SPSC queue to form MPMC:

https://books.google.ca/books?id=jZG_DQAAQBAJ&pg=PA276&lpg=PA276&dq=SPSC+and+queue+and+MPMC&source=bl&ots=KwfRYpYWW3&sig=GYE7Sn7ZlhNsJISvTjV4bXnjvDc&hl=en&sa=X&ved=0ahUKEwia4fKKjojaAhUCuVkKHZnbBvMQ6AEIjgEwCQ#v=onepage&q=SPSC%20and%20queue%20and%20MPMC&f=false


As you have noticed a matrix of (N-1)*(N-1) SPSC queues
is needed to compose an MPMC queue , and strict FIFO order that can be
broken in it, this is not good, this is why i said before:

Other than the strict FIFO order that can be broken, here is another
problem with the distributed network of SPSC queues, here it is:


--

5. finally, SPSC may not be a good point for massive ITC(inter-thread
communication):.

Because the space complexity goes in O(N^2), N is the number of threads.
It is not rare to see a server with 1k or 2k hardware threads. And "many
core" is the final destination of CPU from current sight.

---


Read all the following webpage and the responses to it to understand:

https://www.infoq.com/articles/High-Performance-Java-Inter-Thread-Communications

So i think my scalable FIFO queue algorithm and its implementation is
an invention and it is still useful.

[computer45]

Read again about network of SPSC queues to form MPMC:

https://books.google.ca/books?id=jZG_DQAAQBAJ&pg=PA276&lpg=PA276&dq=SPSC+and+queue+and+MPMC&source=bl&ots=KwfRYpYWW3&sig=GYE7Sn7ZlhNsJISvTjV4bXnjvDc&hl=en&sa=X&ved=0ahUKEwia4fKKjojaAhUCuVkKHZnbBvMQ6AEIjgEwCQ#v=onepage&q=SPSC%20and%20queue%20and%20MPMC&f=false


As you have noticed a matrix of (N-1)*(N-1) SPSC queues

is needed to compose an MPMC queue , and strict FIFO order can be broken
in it, this is not good, this is why said also:

Other than the strict FIFO order that can be broken, here is another
problem with the distributed network of SPSC queues, here it is:


--

5. finally, SPSC may not be a good point for massive ITC(inter-thread
communication):.

Because the space complexity goes in O(N^2), N is the number of threads.
It is not rare to see a server with 1k or 2k hardware threads. And "many
core" is the final destination of CPU from current sight.

---


Read all the following webpage and the responses to it to understand:

https://www.infoq.com/articles/High-Performance-Java-Inter-Thread-Communications

So i think my scalable FIFO queue algorithm and its implementation is
an invention and it is still useful.

[Tim Rentsch]

cr...@spitfire.i.gajendra.net (Dan Cross) writes:

> I know better than to engage with a known troll, but....

but... some days you just have poor impulse control?

(just a friendly rib - I must plead guilty to the same
offense :)