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 years ago.
Improve this question
Can we say that the C# async/await pattern is some kind of
(smart) sugar syntax ?
Because as far as I can see, at the very end, it "just" hides all the implementation of an (internal) worker thread for the programmer.
Yes, there is no CLR support for await. It goes away on compilation. Anything you can write with await you can write without it.
Awaiting tasks it is a fancy way of calling ContinueWith :)
Decompile an assembly that uses await to see how it works under the covers.
async/await is indeed syntactic sugar, however, it doesn't just hide threads. Just because you use async and await in a method does not mean that you are creating threads.
From the MSDN Article Asynchronous Programming with Async and Await (C# and Visual Basic):
The async and await keywords don't cause additional threads to be
created. Async methods don't require multithreading because an async
method doesn't run on its own thread. The method runs on the current
synchronization context and uses time on the thread only when the
method is active. You can use Task.Run to move CPU-bound work to a
background thread, but a background thread doesn't help with a process
that's just waiting for results to become available.
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 3 years ago.
Improve this question
I have multi-core laptop and I wanna make my application more faster on that machine, I think async-await and parallel programming help to achieve that feat.
Typically, Async and await is more about not blocking the current thread during a long-running operation.
Typically, parallel processing is used when the goal is to achieve an increase in performance.
That said, I think it's not uncommon to see both used together--you might have a desktop app that you want to ensure the UI thread is not blocked while you perform a long-running operation
so you could use Async and await to start the long-running operation on a non-UI thread (this way, your desktop app's GUI can still be responsive while the long-running operation is running on another thread
and you might also decide to introduce parallelism in the implementation of that long-running operation to have it complete faster
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
I am new to asynchronous programming in .Net using C#. All I have understood so far is :
With asynchronous programming, threads that are waiting for a web service or database to return data are freed up to service new requests until the data the is received.
Once the data is received, the thread is restarted and continue processing the code that comes after that call.
Now , I wanted to know in details How the state is managed for the thread so that it can start executing from the point the async call was made.
If it uses a stack to handle that, Can some one please give me an insight into the process?
Thanks,
Mayank
Now , I wanted to know in details How the state is managed for the thread so that it can start executing from the point the async call was made.
Async method are divided into smaller chunks. Basically, when compiling async method, for every await keyword new method is generated.
Keep in mind, that this is a big simplification and it's all done behind the scenes and you really don't need to know how it works in order to use it.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
In synchronous programming (before async/await arrived on the scene) it was clear to me how or why cross-thread exceptions occurred. If I launched a background thread to do some heavy task so as to offload UI thread and make it responsive, I knew exactly what to do to access UI thread from the background thread. If in doubt I could even check in what thread a given code was executing.
With async/await asynchronous programming, I find what was a clear-cut identification of threads somehow blurred and murky (even well demonstrated in debugging with call stacks jumping all over the place based on numerous awaited tasks).
What I try to find out is a kind of roadmap that would help me identify cross-thread danger areas/pitfalls along the bumpy async/await meander (forgive the metaphor).
What, exactly, would I be watching for to avoid cross-thread exceptions when it comes to asynchronous programming? Can these be made into some kind of checklist?
I cover the main threading considerations in my async intro. To be specific, the default behavior of await is to capture a "context" and then resume the method within that "context". In the case of a UI thread, that context will cause the async method to resume on the UI thread.
So, plain async and await simply avoid most cross-threading concerns completely.
Note that if you do introduce background threads (e.g., Task.Run), then of course those background threads can cause cross-threading exceptions and you'll have to avoid those appropriately.
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 8 years ago.
Improve this question
I can't understand the difference between Thread.Sleep() and synchronous methods. Please explain..
Is synchronous method in C# is similar to Thread.Sleep()?.
No, other than Thread.Sleep is a synchronous method.
A synchronous method is one where the entirety of their functionality happens before returning control to the caller.
Thread.Sleep is a function which causes the executing thread to block for the specified number of milliseconds (not exactly, but close due to the CPU thread scheduler). It executes synchronously and wouldn't be as useful in an asynchronous method.
However, saying they are the same thing would be a misnomer, as there are plenty of synchronous methods that are not Thread.Sleep and do not use it either.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
I like a thread to be reused for many Tasks, but can I force a Task to only run in the same Thread?
Follow-up
Always nice to come back on SO to see 5 downgrades. Actually I think the question has relevance. Today I'm using threads and this works okay but the threads are sleeping most of the time. Tasks would solve this. But the threads are using a resource that can only be created and accessed from the same thread. Now you know why I asked.
Yes you can, you can do this through either using a TaskScheduler, or alternatively through using a SynchronizationContext. Either is a means that will allow you to have any number of tasks running under the same thread, possibly even the thread that created the task.
If you're creating the Task in a UI context where there is already a SynchronizationContext then you can just pass that in. If not, you would need to make your own context to both pass to the task and determine how the task(s) passed to it should be executed. You could create a new sync context, give some tasks to it, and then have it execute them all in the current thread, if you wanted. Here is a blog post with an example of that exact concept. It has a link with all of the code used in the whole series on the subject.
I am pretty sure this is not possible using Task as Task does not (as I understand them) garanty to use a seperate thread to execute the Task. You can certainly do this however using threads themselves and writing your code to use the same thread. Just remember that once a thread stops it can't be restarted.