Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I am recording multiple usb cameras using a 3rd party library. For that I record each camera’s data on a separate thread in C#. The problem is that application sometimes fails to fetch all the data.
Therefore I wonder if opening the C# threads might block my CPU threads as my CPU is 4 core / 4 threads. Are CPU cores/threads related to threads we initialize in C#?
Well, it depends on how you're going to accomplish this task. Recording camera video probably comes as a functionality of some 3rd party library, and that lib's API may already need your UI (main) thread in order to do do a task. If you're implementing your own low-level recording API and wish to receive data from that API then you may want to run data fetching in a separate thread simply using:
Task.Run(()=> {
// new thread running - your data fetching code here
});
This way, your main thread won't be blocked and awaiting on the new thread will yield the results from your camera API.
That totally depends on the way you are using the thread. I can think of at least 3 different scenarios - 1. Your cameraThread is defined as a high priority, and as such (even with the time slicing) takes 99% of the time. 2. Your cameraThread is run with the tasks thread pool, and as such it is being blocked and is blocking at random with other threads (resource contention). and 3. your camera recorder is happening in a low priority in the background.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 months ago.
Improve this question
Reading about how does the OS handle the executables, I couldn't figure out if is better to use one executable with many threads inside or use many independent executables. The same task is performed, but I need to process many requests. Is there an executable limits to run simultaneous threds? Does it matter or every OS task goes to same CPU queue and doesnt matter the source executable?
Which is better? One with many threads or many executables? If could give an explanation or share some doc I would be greateful.
As far as the OS scheduling them to CPUs, there's no difference; modern mainstream OSes (Windows / Linux / MacOS) use a 1:1 thread model so every user-space thread is a separately schedulable OS task, not "green threads".
Solaris did or does have an N:M thread model, where user-space threads can be scheduled onto a "thread pool" of OS-level threads, with user-space context switching in some cases, but most other OSes don't.
So either way can take full advantage of all the CPU cores in the system; which is better depends on the use-case. Threads of a single process share memory (and file descriptors) with each other, and are cheaper to create than new processes. But still not that cheap; often you want to have a pool of worker threads that you wake up or queue work for, not start a new thread or process when a new request comes in.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
This is more of a knowledge thing. I just wanted to know whether its possible or not. And would be helpful to give also justification to either case.
Since someone thought they need more explaination and held my question. So here for them
Basically the scenario which I am trying to tackle is that. I have a console app which has an API to call to Native code (with lot of global state) and only one thread could call the native code in a given time.
My console app launches multiple thread doing lot of calculations while they want to call Native code also within them.
Now I have following doubts or could be my lack of understanding (please excuse)
If I use lock{} to each native calls then I can stop only one thread going to the core thats good, but just imagine if THREAD 1 and THREAD 2 waiting for the lock then who gets the lock first? is it the First come first serve or whether its in-deterministic?
If its in-deterministic then I would want to dispatch all my calls for Native API from different thread to be dispatched to the main console app running thread.
possible? sure thing ... as long as you define something as a main thread ...
since by default there is no message loop you'd have to make something up, or get a reference to winforms Application class or WPFs dispatcher, and fire one of those up ... they should work regardless of the fact that there is no winforms or wpf ui if you start them
if you have code in your application that needs certain operations to be done on a certain thread ... why not dispatch things to the right thread?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have a process that connects to a host and infinitely checks if there is new data to process.
My application has close to 500 threads and each thread runs in an infinite loop..
Here's the code :
for(i=1; i<=500; i++)
{
Thread instanceCaller = new Thread(new ThreadStart(infiniteProcess));
instanceCaller.Start();
}
Is there a better way to write this code using C# async. Also, will there be any performance improvements if we use async instead of threadstart.
I want to clarify why I would like to create 500 threads and having a thread pool doesn't work for me.
Basically, each of this thread opens a dedicated socket connection to the host. The host sends a message to this socket which is then routed to the appropriate destination (configured in the DB). The destination could be a hardware device (printer etc., ) or some other device.
We cannot create thread pools because, each of this thread is very active and continuously receives messages from the host and processes them. The overhead of loading and unloading threads from the thread pool is inefficient.
My original application created using threads works well.. But I would like to see if there is any way we can improve the efficiency by taking advantage of new features in C# 5.0.
When you get into the hundreds of threads you should consider replacing blocking by asynchronous IO and asynchronous waiting. Many threads cause high memory usage and OS scheduling overhead.
Try to remove the calls that block the longest first. Apply the 80-20 principle. You don't have to go all async.
That said the overheads associated with this many threads are generally overestimated. Your code will not suddenly become 2x faster if you go all async. Async really only changes the way an operation is started and ended. The operation itself (the IO or the wait) is not accelerated at all.
Also, async does not add capacity. Your CPUs don't become faster, the database cannot handle more operations and the network has a fixed throughput as well. Async IO is really about saving memory and scheduling overhead.
You will not hit OS limits with 500 threads. I recently created 100,000 threads on my machine using testlimits.exe without much trouble. The limits are really high.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions concerning problems with code you've written must describe the specific problem — and include valid code to reproduce it — in the question itself. See SSCCE.org for guidance.
Closed 8 years ago.
Improve this question
I am developing a WPF program which performs long running tasks in the background, using TPL's Parallel.ForEach.
I have an image control and when am trying to show an image, it seems that the image rendering happens in the thread pool, and since I use it intensively (via TPL Forech) the rendering is extremely slow.
Is there a way to perform the image rendering in higher priority or not in the thread pool ?
Parallel.ForEach is designed to use as much of your CPU as it can get hold of. If you don't want it to do that, then either don't use it (just run the long-running task in a single poll thread), or control the amount of your CPU which 'Parallel.ForEach' uses, by passing in a 'ParallelOptions' object to limit its appetite for CPU.
You also say you're running 'long running' tasks using Parallel.ForEach - bear in mind that it's designed for getting cpu-bound tasks finished quickly, not backgrounding things which are long-running because they're waiting for I/O (for example). From the symptoms though, it does sound like you're using it for the right thing, it's just that it's using more CPU than you want.
As far as trying to avoid the thread pool, I think you're barking up the wrong tree - it's just a collection of threads which already exist, designed to avoid the overhead of creating and destroying threads all the time - it's not a priority mechanism - what your two activities are fighting over is access to the CPU, not access to the thread pool.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I am just finding my way around parallel programming in C# and understood the significance of cores and true parallel programming.
But I still have a question:
Say I have a long running task does that mean this will be executed using threads from thread pool and in different cores for true parallel programming.
Or does it depend on the actual delegate that is passed onto the task?
I Hope my question is clear.
The delegate itself makes no difference. It is the TaskScheduler that matters.
The default TaskScheduler will run them via the ThreadPool.. to have them run synchronously, you would pass in a TaskScheduler instance that is currently being used.. such as the static TaskScheduler.FromCurrentSynchronizationContext.
True parallel programming requires multiple cores since threads must execute on separate threads to truly run in parallel.. In a single core system you can only achieve fake parallelism since different treads must share the core through allocated time slots. Other treads are waiting while the current thread is running on the single core.