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.
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 2 years ago.
Improve this question
Is it safe to call File.WriteAllTextAsync to write to a single file multiple times without awaiting the result, as long as all the calls are made in a single thread?
By safe I mean:
no IO exception will be thrown
afterwards the file will have the content of the last call made
This seems to run fine, but is it guaranteed to do so?
for (var i = 0; i < 1000; ++i)
{
File.WriteAllTextAsync(fileName, i.ToString());
}
No, it is not safe. You may get "File already in use " exception.
Either you need await or do it synchronously.
No, it's not safe. It is not guaranteed that no exceptions will be thrown¹ or that all text will be written in the file. The only reason that it seems to work is because the asynchronous filesystem APIs are not implemented efficiently in .NET, and most of them block the calling thread instead of launching the operations asynchronously as they should. My suggestion is to use the synchronous API instead (File.WriteAllText).
¹ It is possible though that the thrown exceptions will remain unobserved, since the asynchronous operations are launched in a fire-and-forget fashion.
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 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.