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

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

Re: More about WaitAny() and WaitAll() and more..

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: More about WaitAny() and WaitAll() and more.. Bonita Montero <Bonita.Montero@gmail.com> - 2021-04-25 00:10 +0200
    Re: More about WaitAny() and WaitAll() and more.. Amine Moulay Ramdane <aminer68@gmail.com> - 2021-04-24 15:50 -0700
      Re: More about WaitAny() and WaitAll() and more.. Bonita Montero <Bonita.Montero@gmail.com> - 2021-04-25 01:41 +0200
    Re: More about WaitAny() and WaitAll() and more.. Amine Moulay Ramdane <aminer68@gmail.com> - 2021-04-24 16:00 -0700
    Re: More about WaitAny() and WaitAll() and more.. Amine Moulay Ramdane <aminer68@gmail.com> - 2021-04-24 16:18 -0700

#6401 — Re: More about WaitAny() and WaitAll() and more..

> https://sites.google.com/site/scalable68/an-efficient-threadpool-engine-with-priorities-that-scales-very-well

Having different priorities for the queue-items is absolutely
_wrong_ ! Therefore you should use multiple thread-pools whose
threads get different priorities and the fairness much more
accurately realised by the scheduler.

[toc] | [next] | [standalone]

#6402

On Saturday, April 24, 2021 at 6:10:06 PM UTC-4, Bonita Montero wrote:
> > https://sites.google.com/site/scalable68/an-efficient-threadpool-engine-with-priorities-that-scales-very-well 
> 
> Having different priorities for the queue-items is absolutely 
> _wrong_ ! Therefore you should use multiple thread-pools whose 
> threads get different priorities and the fairness much more 
> accurately realised by the scheduler.


I think you are wrong, since you have not to manage priorities of processes and threads
by your way, since this can introduce more complexity and this can lead to priority inversion, so i think 
that my methodology is good. So i understand your objections, but i think with the way 
of your thinking you can get into complexity and problems.

Thank you,
Amine Moulay Ramdane.

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

#6405

No, I'm not wrong. Having different scheduling-properties is
a much more fine graineed kind of having different priorites.

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

#6403

On Saturday, April 24, 2021 at 6:10:06 PM UTC-4, Bonita Montero wrote:
> > https://sites.google.com/site/scalable68/an-efficient-threadpool-engine-with-priorities-that-scales-very-well 
> 
> Having different priorities for the queue-items is absolutely 
> _wrong_ ! Therefore you should use multiple thread-pools whose 
> threads get different priorities and the fairness much more 
> accurately realised by the scheduler.

I think i have answered your question before, but i will add something really important:

Your way of doing is the wrong way, because you are coming from the way of C++ thinking and 
this way of thinking has a "tendency" to stupidly get into more complexity 
that is more difficult to manage, but my way of doing is that i am looking 
to efficiently minimize complexity, so our philosophies are not the same. 
And i will give you more logical proof by giving you some real world examples
of your kind of stupidity from PhD  research so that to understand. 

Thank you,
Amine Moulay Ramdane.



 

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

#6404

On Saturday, April 24, 2021 at 6:10:06 PM UTC-4, Bonita Montero wrote:
> > https://sites.google.com/site/scalable68/an-efficient-threadpool-engine-with-priorities-that-scales-very-well 
> 
> Having different priorities for the queue-items is absolutely 
> _wrong_ ! Therefore you should use multiple thread-pools whose 
> threads get different priorities and the fairness much more 
> accurately realised by the scheduler.


There is another problem with you getting into more complexity, it is 
that you are seeking to use multiple threadpools by giving them each 
a level of priority, but what we are trying to do is to maximize parallelism,
but with your methology you are not maximizing parallelism, since you can 
get into more thread switches if every threadpool has the same thread number as the number of cores, 
or if you don't want to get into this problem of too much context switches, you will 
get also into another problem by not correctly maximizing parallelism.


Thank you,
Amine Moulay Ramdane.

[toc] | [prev] | [standalone]

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

csiph-web