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 5 years ago.
Improve this question
I'm trying to dispatch my thread as
private Thread thread;
. . .
if(thread != null && thread.IsAlive) thread.Abort();
. . .
thread = new Thread(myProcess);
thread.Start();
to start over myProcess from the very beginning, if it is already run.
However, it never ever comes to thread.Abort(), and WPF UI responce time still quite bad.
How could I make it right way?
So, with all conversations in my post, as well as discussions outside of StackOverflow, I found, that I ask about quite fundamental issue, which haven't any solution is the Microsoft Windows architecture:
When external task started in some thread with API, and it is running, there is no way to cancel this execution, and return it to the initial suspend status, but another API (as "Cancel" in ProgressBar) made specially to return it to the Idle Loop waiting.
In other time sharing OS such a special point exists, but not in Windows.
As a result, when no Cancel API interface described, we should run another thread, possibly, from the tread pool to save CPU time in the system, and keep waiting, until unnecessary one would be completed.
Respond from Tekla developers confirm my conclusion:
"Such methods do not exist. As I wrote before, implementing multi-threading in your app could not improve performance changing colors because TeklaStructures internal code does not use it."
Related
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.
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 5 years ago.
Improve this question
I am learning async/await and I came across the blog in which it's mentioned about using ConfigureAwait with async/await. It read's like this:
ConfigureAwait accepts a Boolean continueOnCapturedContext parameter: passing true means to use the default behavior, and passing false means that the system doesn’t need to forcefully marshal the delegate’s invocation back to the original context and can instead execute the delegate wherever the system sees fit.
The information does not tell much in detail, can anybody explain the real world example of using it. I also searched further and found out that it should be used with HTTP calls and such, but didn't got concrete answer for why should we use it.
Reference link: https://blogs.msdn.microsoft.com/windowsappdev/2012/04/24/diving-deep-with-winrt-and-await/
This is useful for scenarios where a single thread handles multiple actions, think Dispatcher thread in WPF or the host thread in IIS.
It is most obvious in Asp.Net (on Windows and full .net, hosted in IIS) -> if you do not specify .ConfigureAwait(false) and the request takes a significant amount of time, no other requests can be processed by the same w3wp.exe process.
The whole app is essentially blocked.
What this is doing is saying that the control can return to this stack using another thread from the threadpool, essentially unblocking the main 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 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
My question is about the best way to handle long running tasks inside MVC(5) while using SignalR. My application has some long running tasks, some compute bound and some that wait on services, that I run from MVC and then use SignalR to handle progress messages and cancellation.
My current implementation, which was started before async/await was out, registers the class/method in a concurrent dictionary with an id. MVC then returns an Id back to a Ajax call and then exits the view. The JavaScript sends a 'Start' message with the Id to SignalR which then recovers the class from the dictionary and then calls the long running method, i.e. blocks the Hub.
I did this on the grounds that, to be honest, it was easier that way as Tasking is hard work in ASP.NET. It also means that progress messages, which includes fairly detailed text progress messages, can use the existing Hub instance. The down side is that, I assume, SignalR keeps a thread open all the time, which isn't good.
I am now relooking at this design in light of async/await. I could change the design so that the SignalR Hub awaits a task, so freeing up the thread. Is that the best way? I assume I will then take a hit creating SignalR Hubs to send my messages, so overall it might take more processing power. However it would scale better.
Does anyone have an experience of this, as it must be a fairly standard use of SignalR in MVC. All thoughts/experiences welcome.
There's no point in making a CPU-bound background task be asynchronous, but you could do that with your I/O-bound background tasks.
If you use async/await, the hub is still there; I don't see why that would require additional hubs. SignalR understands async.
On a side note, you do want to make sure your background tasks are reliable, as #usr noted. I wrote a blog post last weekend summarizing various ways to (semi-safely) perform background work on ASP.NET.
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
Hi I am new to windows service I have developed one windows service using the threading that creating new thread in OnStart() and running methods using that thread and using sleep thread to next run time but one of my friend said it is better to use timer than thread so I was wondering which is best way to do the program ? Thanks for the help
Based on your comment that your goal is to run some code at specific intervals:
Conceptually it is better to use a timer than to make your thread sleep. This is what timers are made for. If you choose the thread sleep approach instead I think that in practice it will work fine anyways, although the better practice is to use timers.
There is a third approach - using a job scheduler. You can use windows task scheduler or the more powerful quartz.net (nuget package here).
This is really a question about how you value semantic correctness to pragmatism.
From a semantic correctness perspective the best approach is to use a job scheduler since you actually want to schedule a job.
From a pragmatic perspective the best approach is probably to just continue using the service you already developed even though it makes the thread sleep, and spend your time on something else than modifying your fully working code.
More opinions about timer vs. job scheduler: Best Timer for using in a Windows service
It depends on what you are doing i suppose. The difference betweeen Timer and Thread is that Timer uses a thread from the thread pool, whereas Thread dedicates a new one for the task.
You can read more here: http://social.msdn.microsoft.com/Forums/vstudio/en-US/c5b0e037-ccb5-42c0-bb0a-304572c8c8d2/timer-vs-thread-performance