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.
Related
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."
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 was asked at an interview today about how I would implement my own Thread. As a hint I was told that implmenting Runnable was one thing to consider, and what are the others?
I was completely stumped but even after researching it online, I still have no idea what the answer is or if it was even a valid question. I'm leaning towards the latter.
So my question is:
What things would you need to consider if you wanted to write your own implementation of the Thread class in C#?
First up, Runnable probably refers to Action. Action is a delegate type used to store a reference to a method. You use this to tell a thread what method to start on.
I expect they only wanted you to illustrate how to;
start a thread with a delegate (that is how Runnable enters the fray).
-or-
schedule work to be performed on a worker thread. I would use a call to Task.Run(new Action(....)) for this. It is concise and modern.
I would always do the latter until instructed to detail the lower level Thread class.
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
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.