1

Topic: It is a lot of Thread or ThreadPool

I welcome. A question on architecture and competent usage of resources. In general the circuit such - it is necessary to collect operations (we assume from basis or queue) and further them to execute. Simultaneously it is possible to execute no more than 50-100 operations (it is impossible more) There are two variants. 1) to create a flow for collection of operations new Thread and after assembled operations to execute (normally 2-5 ) adding them in ThreadPool 2) to Create 50-100 flows and start up permanently listen to basis or queue and execute on one operation. What from the point of view of system will be more correct and it is less exacting to resources (more cheaply)?

2

Re: It is a lot of Thread or ThreadPool

Hello, alexsoff, you wrote: A> I Welcome. A> a question on architecture and competent usage of resources. A> in general the circuit such - it is necessary to collect operations (we assume from basis or queue) and further them to execute. Simultaneously it is possible to execute no more than 50-100 operations (it is impossible more) A> There are two variants. A> 1) to create a flow for collection of operations new Thread and after assembled operations to execute (normally 2-5 ) adding them in ThreadPool A> 2) to Create 50-100 flows and start up permanently listen to basis or queue and execute on one operation. A> that from the point of view of system will be more correct and is less exacting to resources (more cheaply)? I would dig aside TPL (ActionBlock any, for example) 100 flows are more than time among themselves for the processor will fight, rather than to fulfill the useful operation.

3

Re: It is a lot of Thread or ThreadPool

Hello, alexsoff, you wrote: A> I Welcome. A> a question on architecture and competent usage of resources. A> in general the circuit such - it is necessary to collect operations (we assume from basis or queue) and further them to execute. Simultaneously it is possible to execute no more than 50-100 operations (it is impossible more) A> There are two variants. A> 1) to create a flow for collection of operations new Thread and after assembled operations to execute (normally 2-5 ) adding them in ThreadPool A> 2) to Create 50-100 flows and start up permanently listen to basis or queue and execute on one operation. A> that from the point of view of system will be more correct and is less exacting to resources (more cheaply)? Flows are  in.NET. That we deal so-called managed thread instead of a real flow of execution, and finishing modern Frejmvorkami where even   to learn - and that not always it is authorized. So, Task - our all (ContinueWith, async/await and other).  it is possible to create a nested sheaf principal-affiliated, it is possible easily , it is not necessary to think of that as the scheduler  distributes quanta.

4

Re: It is a lot of Thread or ThreadPool

At first "the basis or queue" is a serious distinction. 50-100 flows (not important fair or Task') can listen rather cheaply to queue (e.g. The same RabbitMQ), and here if they will water basis is already not sickly loading it turns out. Further, much depends on the interface  the data. Whether it can give given by a pack, or only by the piece? Whether there is a communication under the data (e.g. The result of handling of the first operation is necessary for ) or all operations independent? Whether there are locks at reading (i.e. whether locks reading consumer remaining) and how much they serious? Whether it is necessary reportit/kvitirovat result of handling? Time of handling of a portion of the data approximately equally or can spring in notable limits? If springs, whether that important to observe uniformity of loading consumer' i.e. if one finished operation before remaining - it is necessary to load it at once or it is possible to wait while finish the remaining? 50-100 operations are that, a limit producer'a (i.e. The source can produce "no more than" in unit of time) or consumer' (i.e. there should not be more than 50-100 simultaneously processed tasks)?

5

Re: It is a lot of Thread or ThreadPool

Hello, RushDevion, you wrote: RD> At first "the basis or queue" is a serious distinction. In the core queue, sometimes basis. RD> 50-100 flows (not important fair or Task') can listen rather cheaply to queue (e.g. The same RabbitMQ), and here if they will water basis is already not sickly loading it turns out. That's it, I always considered than less flows as that the system faster works for us as a whole since a considerable quantity of flows very expensively to service. Unless it not so? RD> Further, much depends on the interface  the data. Whether RD> it can give given by a pack, or only by the piece? Logically by the piece, and so in implementation is Prefetch (judging by source codes of the provider to queue) so for 2-3 messages I follow some clock periods of the processor (measured StopWatch). Whether RD> There is a communication under the data (e.g. The result of handling of the first operation is necessary for ) or all operations independent? Independent (logically dependent, but after handling go to other jobs in basis/turn) whether RD> There are locks at reading (i.e. whether locks reading consumer remaining) and how much they serious? Certainly. Whether RD> it is necessary reportit/kvitirovat result of handling? No. RD> Time of handling of a portion of the data approximately equally or can spring in notable limits? 99 % time of 2-5 seconds. RD> if springs, whether that important to observe uniformity of loading consumer' i.e. if one finished operation before remaining - it is necessary RD> to load it at once or it is possible to wait while finish the remaining? Uniformity of loading is reached by restriction of the maximum quantity on process of processed messages. RD> 50-100 operations are that, a limit producer'a (i.e. the source can produce "no more than" in unit of time) RD> or consumer' (i.e. there should not be more than 50-100 simultaneously processed tasks)? Simultaneously processed tasks.

6

Re: It is a lot of Thread or ThreadPool

Hello, Mr. Delphist, you wrote: MD> So, Task - our all (ContinueWith, async/await and other).  it is possible to create a nested sheaf principal-affiliated, it is possible easily , it is not necessary to think of that as the scheduler  distributes quanta. , Task with lifetime of application it unless not a perversion? Whether to create a flow separate more correctly?

7

Re: It is a lot of Thread or ThreadPool

Hello, alexsoff, you wrote: A> Hello, Mr. Delphist, you wrote: MD>> So, Task - our all (ContinueWith, async/await and other).  it is possible to create a nested sheaf principal-affiliated, it is possible easily , it is not necessary to think of that as the scheduler  distributes quanta. A> , Task with lifetime of application it unless not a perversion? Whether to create a flow separate more correctly? For this purpose exists TaskCreationOptions. LongRunning http://qaru.site/questions/120236/taskc … threadpool

8

Re: It is a lot of Thread or ThreadPool

Hello, Serginio1, you wrote: A>> , Task with lifetime of application it unless not a perversion? Whether to create a flow separate more correctly? S> for this purpose exists TaskCreationOptions. LongRunning http://qaru.site/questions/120236/taskc … threadpool looked, they there  https://stackoverflow.com/questions/102 … anually-in Although this is undocumented, if you start a Task with TaskCreationOptions. LongRunning then a new Thread will be started to run the Task. So the sense in  is not present and in bowels all the same there is a selected flow new Thread.

9

Re: It is a lot of Thread or ThreadPool

A> That's it, I always considered than less flows as that the system faster works for us as a whole since a considerable quantity of flows very expensively to service. Unless it not so? Certainly operation of the scheduler of flows of OS imports any overhead projector (support of queue of flows, switching of contexts, etc.) . But the typical flow is not only calculations, but also input-output operations. The flow waiting for input-output does not spend CPU time, and, means, the scheduler can give to its other flows. Latency of performance of each specific operation thus decreases. And being returned to the task. I would make so. One flow which reads to the data, distributes tasks to executors and supervises an amount in-progress tasks. Something of type such: private readonly ManualResetEvent m_StopEvent = new ManualResetEvent (false); private int m_PendingWorkItems; private const int MAX_WORK_ITEMS = 100; public void WorkerRoutine () {while (m_StopEvent. WaitOne (TimeSpan. FromSeconds (5)))//Sleep 5 seconds {var pendingWorkItems = Volatile. Read (ref m_PendingWorkItems); if (pendingWorkItems> MAX_WORK_ITEMS) continue; var workItems = m_DataProducer. GetWorkItems (MAX_WORK_ITEMS - pendingWorkItems); foreach (var workItem in workItems) {var item = workItem; Interlocked. Increment (ref m_PendingWorkItems); Task. Factory. StartNew (() => {try {ProcessWorkItem (item);} finally {Interlocked. Decrement (ref m_PendingWorkItems)}});}} MD>> so, Task - our all (ContinueWith, async/await and other).  it is possible to create a nested sheaf principal-affiliated, it is possible easily , it is not necessary to think of that as the scheduler  distributes quanta. A> , Task with lifetime of application it unless not a perversion? Whether to create a flow separate more correctly? Yes, in general, . For  with flag LongRunning   all the same creates a separate flow.

10

Re: It is a lot of Thread or ThreadPool

Hello, RushDevion, you wrote: RD> And being returned to the task. RD> I would make so. RD> [skip] it is excellent, though thoughts converge with someone, I made about same, truth on semaphores at them there is counters - very conveniently. Since it is no more operations 100 and duration of 2-5 seconds, losses on an input in a kernel mode () can be neglected.

11

Re: It is a lot of Thread or ThreadPool

At implementation, of course, to look. I so understand, or for everyone work item'a the separate flow (or ) which tries to capture a semaphore before the handling beginning will be wounded. Or there are 50 flows + 1 producer + the general queue of tasks ready to handling. Other variants  to a head does not come. Then in the first case can receive in vain idle flows if   the data faster, than has time to process them. And in the second case we receive an overhead projector on  access to queue.

12

Re: It is a lot of Thread or ThreadPool

Hello, alexsoff, you wrote: A> , Task with lifetime of application it unless not a perversion? Whether to create a flow separate more correctly? The concept "correctly" here is not absolutely correct. You does not disturb, variable resetting to zero how becomes: zero copying in the register or XOR AX, AX? Though on  , I put xor because on clock periods quitted faster. Well and it who hinders instead of a taska-long-liver to make generations, when short-lived  before death  the new task on execution.

13

Re: It is a lot of Thread or ThreadPool

Hello, RushDevion, you wrote: RD> at Implementation, of course, to look. RD> I so understand, or for everyone work item'a the separate flow (or ) which tries to capture a semaphore before the handling beginning will be wounded. Yes, this variant true. RD> in the first case can receive in vain idle flows if   the data faster, than has time to process them. About 90 % of cases the data is processed faster, than them .

14

Re: It is a lot of Thread or ThreadPool

RD>> at Implementation, of course, to look. RD>> I so understand, or for everyone work item'a the separate flow (or ) which tries to capture a semaphore before the handling beginning will be wounded. A> yes, this variant true. RD>> in the first case can receive in vain idle flows if   the data faster, than has time to process them. A> about 90 % of cases the data is processed faster, than them . Too a working variant but how to be said, eat nuances At first, worker threads any time can stand idle. For example, if the data for handling meanwhile is not present - ours 50-100 flows stupidly wait on the monitor. And could do something useful Secondly if to speak about efficiency the overhead projector on monitor capture is ~ 250ms. And Interlocked-operation ~10ns.

15

Re: It is a lot of Thread or ThreadPool

Hello, alexsoff, you wrote: A> Hello, Serginio1, you wrote: A>>> , Task with lifetime of application it unless not a perversion? Whether to create a flow separate more correctly? S>> for this purpose exists TaskCreationOptions. LongRunning http://qaru.site/questions/120236/taskc … threadpool A> looked, they there  A> https://stackoverflow.com/questions/102 … anually-in A> A> Although this is undocumented, if you start a Task with TaskCreationOptions. LongRunning then a new Thread will be started to run the Task. A> so the sense in  is not present and in bowels all the same there is a selected flow new Thread. The sense is what not to mix flows and tasks. Normally LongRunning you are necessary for  and other using  on 100 % In the majority of cases inside LongRunning as can use  asynchronously.

16

Re: It is a lot of Thread or ThreadPool

Hello, RushDevion, you wrote: RD> For example if the data for handling meanwhile is not present - ours 50-100 flows stupidly wait on the monitor.  why? So if flows from ThreadPool (Task. Factory. StartNew) are not used time considerable quantity then it like them releases?

17

Re: It is a lot of Thread or ThreadPool

RD>> For example if the data for handling meanwhile is not present - ours 50-100 flows stupidly wait on the monitor. A> Em why? So if flows from ThreadPool (Task. Factory. StartNew) are not used time considerable quantity then it like them releases? Whence such information? The Tred-pool is arranged as. Is work queue where QueueUserWorkItem places the task. It, by the way, managed a piece, i.e. she on side CLR lives. Also there is (conditionally) array of the precreated flows. It already  the virtual machine.NET. The flow takes the task from queue and starts it to fulfill. Reaches to semaphore. Wait () also rises in state WaitSleepJoin. In this state it and will stick out, while semaphore does not beep.

18

Re: It is a lot of Thread or ThreadPool

Hello, RushDevion, you wrote: RD> the Tred-pool is arranged as. RD> Reaches to semaphore. Wait () also rises in state WaitSleepJoin. I about a case when on handling was not present tasks and in semaphore. Wait it is not caused. I.e. all created tasks through StartNew were completed and in queue there are no new tasks. Logically to assume that works "the assembly" mechanism  not the active flows. Here found acknowledgement of the words with msdn link Beginning with the net_v40_short, the thread pool creates and destroys worker threads in order to optimize throughput, which is defined as the number of tasks that complete per unit of time

19

Re: It is a lot of Thread or ThreadPool

RD>> Reaches to semaphore. Wait () also rises in state WaitSleepJoin. A> I about a case when tasks on handling are not present and in semaphore. Wait it is not caused. A> I.e. all created tasks through StartNew were completed and in queue there are no new tasks. Logically to assume that works "the assembly" mechanism  not the active flows. Indeed. If there was an overabundance of flows ThreadPool cleans superfluous (at least in.NET 4 and is higher). But for this purpose the flow should be inactive (Suspended). And in your case each of 50-100 flows on a cycle or  next work item (Running), or waits on a semaphore (WaitSleepJoin). Well or I not quite caught details of your implementation

20

Re: It is a lot of Thread or ThreadPool

Hello, RushDevion, you wrote: RD> Well or I not quite caught details of your implementation by One flow through new Thread living throughout application operation we run on basis/turn and we obtain the data for later processing. Further through Task. Factory. StartNew we launch  for performance of efficiency duties. We limit all it is a semaphore

21

Re: It is a lot of Thread or ThreadPool

A> by One flow through new Thread living throughout application operation it is run on basis/turn and it is obtained the data for later processing. A> further through Task. Factory. StartNew it is launched  for performance of efficiency duties. A> all is limited it is a semaphore Che all the same vaguely. What that of type such? while (true) {var workItem = getWorkItem (); Task. Factory. StartNew (() => {m_Semaphore. WaitOne ();//Proces... m_Semaphore. Release ();});} If yes generation rate of the data is somehow limited? Because if is not present, there is a risk to receive classical over-subscription: the data arrives more and more (at the fixed speed of consumption). ThredPool starts to increase an amount . And the data more and more the Pool grows as mad. As a result all time is spent for switching of contexts instead of real operation.

22

Re: It is a lot of Thread or ThreadPool

Hello, alexsoff, you wrote: A> I Welcome. A> a question on architecture and competent usage of resources. I do as it is possible is easier and I look as it works: http://rsdn.org/forum/dotnet/6436611.1 the Author: Vladek Date: 05.05.16 all and so works well is normal or bottlenecks appear not there where assumed initially.

23

Re: It is a lot of Thread or ThreadPool

Hello, RushDevion, you wrote: RD> Che it is all the same vague. RD> that that of type such? RD> RD> while (true) {RD> var workItem = getWorkItem (); RD> Task. Factory. StartNew (() => {RD> m_Semaphore. WaitOne (); RD>//Proces... RD> m_Semaphore. Release (); RD>}); RD>} RD> plus still the counter and buffering (x*2) jobs. If the counter exceeds 2x, reading/creating new tasks the flow is locked, before the buffer will be devastated to half. RD> if yes generation rate of the data is somehow limited? Speed of consumption is limited just.

24

Re: It is a lot of Thread or ThreadPool

Hello, alexsoff, you wrote: A> Hello, RushDevion, you wrote: RD>> Well or I not quite caught details of your implementation A> One flow through new Thread living throughout application operation we run on basis/turn and we obtain the data for later processing. A> further through Task. Factory. StartNew we launch  for performance of efficiency duties. A> we limit all it is a semaphore And why it is not used ready ActionBlock from packet Tpl. Dataflow? The one who runs on queue/base simply creates ActionBlock with corresponding MaxDegreeOfParallelism and BoundedCapacity and places elements in queue. Any lack is available or is simple most   more customary?

25

Re: It is a lot of Thread or ThreadPool

Hello, alexsoff, you wrote: RD>> If yes generation rate of the data is somehow limited? A> speed of consumption is limited just. If you want the  look on asynchronous  https://docs.microsoft.com/ru-ru/dotnet … us-pattern look AsyncProducerConsumerCollection and method Add What to do without objects of synchronization could be made 2 queues 1. Queue of tasks on performance where it is possible to regulate depending on the maximum queue length 2. Queue are free tasks. for (var i=1; i <MaxCountTask; i ++) queueFreeTask. Add (1); while (true) {Action act = await queue1.Take (); whether//we take a method on performance from the first stage///we Look there are the free tasks var i = await queueFreeTask. Take (); Task. Run (() => act (); queueFreeTask. Add (1););// the task also we add a sign of the free task in queue} Wrote without studio