Q1. I am aware that subscriber and processor run on separate thread and spin thread handles callbacks. However my doubt is if there are more that 2 subscribers, do all subscribers run on single subscriber thread or 2 subscriber thread ?
Q2. Do Ros Actions and Server run on the spin thread or do they run on their separate thread ?
Related
I have read a lot of node.js system, and I am a little bit confused.
I have a 4 core CPU.
In node.js,
To create a new thread I should do
var child = require('child_process').fork('child.js');
child.on("message", function(){});
This will run the code on new thread under CPU #0.
Each new thread in that way will be created on CPU #0, until the memory will be full.
To use CPU #1 and #2 and #3, I need to use cluster, right?
So I can use both, fork and cluster right?
If cluster use fork so basically it createS only 4 threads? Is that right?
Is process.id a real process id, not thread? not thread id?
So my picture is that:
cpu #0:
thread #0
thread #1
thread #2
thread #3
cpu #1
thread #0
thread #1
thread #2
thread #3
so on..
Am I correct?
Does cluster create only threads?
This is will run the code on new thread under cpu #0.
Wrong. The operating system will determine which core it runs on (and it may not always stay on the same core). That's totally an OS thing. And keep in mind the OS is handling/allocating all threads, not just the node.js threads.
As to the difference between child_process.fork and cluster... From the node.js cluster documentation:
The worker processes are spawned using the child_process.fork()
method, so that they can communicate with the parent via IPC and pass
server handles back and forth.
So cluster is actually using child_process.fork to start with.
But it adds additional functionality on top of this: for example if you are running an http server, cluster can "distribute incoming connections" across the child processes. So if you're not using this for something with incoming connections that need to be distributed, you probably don't need cluster.
More specifically, my application is a network application, a kind of hub in which different endpoint connect and communicate. We need a graphical user interface to monitor the behavior of the participant to the hub, and etc....
Provided of course that the appropriate communication between thread is applied such that for updating the UI thread from another thread etc... does it matter that the GUI thread is the main thread or not.
Up until now, my Gui thread was a separate thread launch from my main thread. However a colleague told me that it was wrong.
Does anyone has some lessons learned or best practice that you could share with me on that subject ?
Many thanks
Maat
What do you mean by "the main thread"?
If you mean "the thread which calls main method", it doesn't matter.
If you mean "the thread which does important work for the application", it should definitely not be the same as GUI thread (which should never run any long-running methods or wait for anything except GUI events).
We are now using Task Parallel Library by implementing Task.Factory.StartNew(). Is there any way to check how many threads does the application spawn when executing the task ?
Currently we are running the application in dual core processor in the development environment.
TPL doesn't spawn any threads when executing a task unless you use a custom scheduler or you pass the TaskCreationOptions.LongRunning option. Even then, it is up to the TaskScheduler used to decide how to treat long-running tasks.
TPL schedules individual tasks to a threadpool for execution by the pool's threads. Each Thread has its own queue to reduce conflicts in multi-core machines. If a thread is too busy, the Framework uses some work-stealing magic to assign the task to an idle thread in the same thread pool.
Check How does the tpl use the CLR thread pool for a bit more info, and this post by Daniel Moth for details on work stealing.
Can we re-purpose the completion port thread (for async I/O operation) as worker thread in CLR process ThreadPool ?
If this is naïve then can someone suggest me how to maximize the use of thread pool threads in order to reduce number of work item stacked in the worker queue.
The IOCP threads are already sorta 'workers' - they take input from a queue and act on the received items. If you wish to avoid using another thread pool for processing items other than 'normal' IOCP completion objects rx from the network drivers, there is nothing stopping you from 'manually' queueing up objects to the IOCP queue that ask the IOCP pool threads to perform other actions. I forget the actual APIs now, but AFAIK there should be no problem.
I remember using such a mechanism for server tuning - reducing the number of IOCP threads by queueing an item that instructed the receiving IOCP pool thread to terminate.
That said, I'm not sure that such a mechansim will improve throughput significantly - the work has to be done somewhere and it may be that avoiding an extra thread pool would not help much. Empirically, as a general-purpose inter-thread comms mechanism, an IOCP queue has a worse performance than Windows message queues, (useless for thread pools anyway since only one thread can wait), and user-space CS/semaphore-based P-C queues.
Rgds,
Martin
I've been reading bunch of articles regarding new TPL in .NET 4. Most of them recommend using Tasks as a replacement for Thread.QueueUserWorkItem. But from what I understand, tasks are not threads. So what happens in the following scenario where I want to use Producer/Consumer queue using new BlockingCollection class in .NET 4:
Queue is initialized with a parameter (say 100) to indicate number of worker tasks. Task.Factory.StartNew() is called to create a bunch of tasks.
Then new work item is added to the queue, the consumer takes this task and executes it.
Now based on the above, there is seems to be a limit of how many tasks you can execute at the same time, while using Thread.QueueUserWorkItem, CLR will use thread pool with default pool size.
Basically what I'm trying to do is figure out is using Tasks with BlockingCollection is appropriate in a scenario where I want to create a Windows service that polls a database for jobs that are ready to be run. If job is ready to be executed, the timer in Windows service (my only producer) will add a new work item to the queue where the work will then be picked up and executed by a worker task.
Does it make sense to use Producer/Consumer queue in this case? And what about number of worker tasks?
I am not sure about whether using the Producer/Consumer queue is the best pattern to use but with respect to the threads issue.
As I believe it. The .NET4 Tasks still run as thread however you do not have to worry about the scheduling of these threads as the .NET4 provides a nice interface to it.
The main advantages of using tasks are:
That you can queue as many of these up as you want with out having the overhead of 1M of memory for each queued workitem that you pass to Thread.QueueUserWorkItem.
It will also manages which threads and processors your tasks will run on to improve data flow and caching.
You can build in a hierarchy of dependancies for your tasks.
It will automatically use as many of the cores avaliable on your machine as possible.