In the example of Socket.BeginReceive() your provided method will be called from a thread-pool thread when the asynchronous operation completes. The assumed behaviour seems to be that you will handle the callback and return, typically having called another async method.
But one could use this as a way to obtain a thread which you then use to manage that socket. Is retaining/monopolising this thread (does this have a proper name) going to cause problems or is it just another worker thread you can use as you want?
Note: I'm aware this isn't the modern paradigm for using Sockets and doesn't scale well
Related
I'm using TaskCompletionSource<> quite often. I have a network protocol design, where I receive many streams in one tcp/ip connection. I demultiplex those streams and then inform the corresponding "SubConnections" of new content.
Those "SubConnections" (which are waiting via await) then should continue in a new thread.
Usually I solve such issues by putting the TaskComplectionSource<>.Set call in an anonymous ThreadPool.QueueUserWorkItem method, like this:
ThreadPool.QueueUserWorkItem(delegate { tcs.SetResult(null); });
If I don't do this the corresponding await tcs.Task call will continue in the thread which called tcs.SetResult.
However, I'm aware of that this isn't the right way to do things. It's also possible to self-write a SynchronizationContext (or something) which will instruct the await call to continue in another thread.
My primary question here is: How would I do this in the "best practice" way?
My hope here is also to avoid the ThreadPool overhead, because it's quite high on Linux compared to just blocking a thread and waiting for a ManualResetEvent - even though the SynchronizationContext (or whatever) may also utilize the ThreadPool.
Please refrain from telling me that it's generally a bad idea to multiplex something in one tcp/ip connection or that I should just use System.IO.Pipelines, REST or whatever. This is my scenario. Thank you.
You can create the TaskCompletionSource using TaskCreationOptions.RunContinuationsAsynchronously (in .NET 4.6+):
var tcs = new TaskCompletionSource<Result>(TaskCreationOptions.RunContinuationsAsynchronously);
...
tcs.SetResult(...);
See e.g. this thread for more details.
I know the differences between a thread and a task., but I cannot understand if creating threads inside tasks is the same as creating only threads.
It depends on how you use the multithreaded capabilities and the asynchronous programming semantics of the language.
Simple facts first. Assume you have an initial, simple, single-threaded, and near empty application (that just reads a line of input with Console.ReadLine for simplicity sake). If you create a new Thread, then you've created it from within another thread, the main thread. Therefore, creating a thread from within a thread is a perfectly valid operation, and the starting point of any multithreaded application.
Now, a Task is not a thread per se, but it gets executed in one when you do Task.Run which is selected from a .NET managed thread pool. As such, if you create a new thread from within a task, you're essentially creating a thread from within a thread (same as above, no harm done). The caveat here is, that you don't have control of the thread or its lifetime, that is, you can't kill it, suspend it, resume it, etc., because you don't have a handle to that thread. If you want some unit of work done, and you don't care which thread does it, just that's it not the current one, then Task.Run is basically the way to go. With that said, you can always start a new thread from within a task, actually, you can even start a task from within a task, and here is some official documentation on unwrapping nested tasks.
Also, you can await inside a task, and create a new thread inside an async method if you want. However, the usability pattern for async and await is that you use them for I/O bound operations, these are operations that require little CPU time but can take long because they need to wait for something, such as network requests, and disk access. For responsive UI implementations, this technique is often used to prevent blocking of the UI by another operation.
As for being pointless or not, it's a use case scenario. I've faced situations where that could have been the solution, but found that redesigning my program logic so that if I need to use a thread from within a task, then what I do is to have two tasks instead of one task plus the inner thread, gave me a cleaner, and more readable code structure, but that it's just personal flair.
As a final note, here are some links to official documentation and another post regarding multithreaded programming in C#:
Async in Depth
Task based asynchronous programming
Chaining Tasks using Continuation Tasks
Start multiple async Tasks and process them as they complete
Should one use Task.Run within another Task
It depends how you use tasks and what your reason is for wanting another thread.
Task.Run
If you use Task.Run, the work will "run on the ThreadPool". It will be done on a different thread than the one you call it from. This is useful in a desktop application where you have a long-running processor-intensive operation that you just need to get off the UI thread.
The difference is that you don't have a handle to the thread, so you can't control that thread in any way (suspend, resume, kill, reuse, etc.). Essentially, you use Task.Run when you don't care which thread the work happens on, as long as it's not the current one.
So if you use Task.Run to start a task, there's nothing stopping you from starting a new thread within, if you know why you're doing it. You could pass the thread handle between tasks if you specifically want to reuse it for a specific purpose.
Async methods
Methods that use async and await are used for operations that use very little processing time, but have I/O operations - operations that require waiting. For example, network requests, read/writing local storage, etc. Using async and await means that the thread is free to do other things while you wait for a response. The benefits depend on the type of application:
Desktop app: The UI thread will be free to respond to user input while you wait for a response. I'm sure you've seen some programs that totally freeze while waiting for a response from something. This is what asynchronous programming helps you avoid.
Web app: The current thread will be freed up to do any other work required. This can include serving other incoming requests. The result is that your application can handle a bigger load than it could if you didn't use async and await.
There is nothing stopping you from starting a thread inside an async method too. You might want to move some processor-intensive work to another thread. But in that case you could use Task.Run too. So it all depends on why you want another thread.
It would be pointless in most cases of everyday programming.
There are situations where you would create threads.
Asynchronous programming is a technique that calls a long running method in the background so that the UI thread remains responsive. It should be used while calling a web service or database query or any I/O bound operation. when the asynchronous method completes, it returns the result to the main thread. In this way, the program's main thread does not have to wait for the result of an I/O bound operation and continues to execute further without blocking/freezing the UI. This is ok.
As far as I know the asynchronous method executes on a background worker thread. The runtime makes availabe the thread either from the threadpool or it may create a brand new thread for its execution.
But I have read in many posts that an asynchronous operation may execute on a separate thread or without using any thread. Now I am very confused.
1) Could you please help clarifying in what situation an asynchronous operation will not use a thread?
2) What is the role of processor core in asynchronous operation?
3) How it is different from multithreading? I know one thing that multithreading is usefult with compute-bound operation.
Please help.
IO (let's say a database-operation over the network) is a good example for all three:
you basically just register a callback the OS will finally call (maybe on a then newly created thread) when the IO-Operation finished. There is no thread sitting around and waiting - the resurrection will be triggered by hardware-events (or at least by a OS process usually outside user-space)
it might have none (see 1)
in Multithreading you use more than one thread (your background-thread) and there one might idle sit there doing nothing (but using up system-resources) - this is of course different if you have something to compute (so the thread is not idle waiting for external results) - there it makes sense to use a background-worker-thread
Asynchronous operations don't actually imply much of anything about how they are processed, only that they would like the option to get back to you later with your results. By way of example:
They may (as you've mentioned) split off a compute-bound task onto an independent thread, but this is not the only use case.
They may sometimes complete synchronously within the call that launches them, in which case no additional thread is used. This may happen with an I/O request if there is already enough buffer content (input) or free buffer space (output) to service the request.
They may simply drop off a long-running I/O request to the system; in this case the callback is likely to occur on a background thread after receiving notification from an I/O completion port.
On completion, a callback may be delivered later on the same thread; this is especially common with events within a UI framework, such as navigation in a WebBrowser.
Asynchronity doesn't say anything about thread. Its about having some kind of callbacks which will be handled inside a "statemachine" (not really correct but you can think of it like events ). Asynchronity does not raise threads nor significantly allocate system ressources. You can run as many asynchronous methods as you want to.
Threads do have a real imply on your system and you have a hughe but limited number you can have at once.
Io operations are mostly related to others controllers (HDD, NIC,...) What now happens if you create a thread is that a thread of your application which has nothing to do waits for the controllers to finish. In async as Carsten and Jeffrey already mentioned you just get some kind of callback mechanism so your thread continues to do other work, methods and so on.
Also keep in mind that each thread costs ressources (RAM, Performance,handles Garbage Collection got worse,...) and may even and up in exceptions (OutOfMemoryException...)
So when to use Threads? Absolutly only if you really need it. If there is a async api use it unless you have really important reasons to not use it.
In past days the async api was really painfull, thats why many people used threads when ever they need just asynchronity.
For example node.js refuses the use of mulptile thread at all!
This is specially important if you handle multiple requests for example in services / websites where there is always work to do. There is also a this short webcast with Jeffrey Richter about this which helped me to understand
Also have a look at this MSDN article
PS: As a side effect sourcecode with async and await tend to be more readable
What I want to do is this--
I want to make a proxy call to a service and receive data on a separate thread through an asynchronous callback...the tricky part is that I want to make the foreground thread sleep until all of the data has been retrieved.
The reason I'm not using a synchronous method to do this, is because I'm creating an API for a WCF service that uses Paging and returns data in chunks.
I want my client to be able to use Paging, but I don't want to expose all of my Paging callbacks to my API...I want it to appear as though the API exposes a synchronous data retrieval method.
I've tried using a private static Semaphore (because it is thread agnostic,) that is accessible to the class methods and the callbacks, with a single unit capacity as a means to pause the execution.
First, I use a Semaphore.WaitOne() statement.
Then, I do a Proxy call in the foreground thread, and the service creates a thread that handles the data retrieval, and control is passed back to the client.
In the client, I immediately use a second Semaphore.WaitOne() statement.
This should pause the foreground thread execution, which it does.
Then, once the "Paging Completed" Callback is executed on a separate thread, I use Semaphore.Release()
But the foreground thread never traverses the second Semaphore statement, it stays locked and so the client freezes.
Any ideas what I am doing incorrectly, or is there another locking design that would be more effective?
If what you're trying to accomplish is having the foreground thread wait on data-gathering thread, you may want to consider using Tasks, which would allow you to easily accomplish what you've described here.
System.Threading.Tasks:
http://msdn.microsoft.com/en-us/library/dd235608.aspx
Some code:
Task t = new Task(somethingToDo);
// Fire off the new task
t.Start();
// Wait for the task to finish...
t.Wait();
// Do something else...
Make sure to take a look at the details of t.Wait() in the documentation. There are some exceptions you will want to be ready for, in the event that your task fails.
I'm referring to this answer where it says it's not required, there are few specific assumptions though. That question is general.
I'm using C#
Asynchronous process is doing nothing but just calling an external API and waiting for the reply.
Generally yes, but there is at least one exception I can think of. To initiate an asynchronous operation you must transfer the operation outside of the context of the caller. What I mean by that is that the caller should not block waiting for the operation to complete. That usually means that the operation has to move to a newly created thread, a thread from the ThreadPool, an IO completion port, another process, or the like.
I said there was one exception that came to mind. If we slightly pervert our definition of asynchronous we can allow for scenarios in which the initiator does not block waiting for the operation to complete without actually moving the operation to another thread. The best example of this is the UI message pump. In .NET it is easy enough to call Control.BeginInvoke from the UI thread itself to post the execution of a delegate on the same thread. The initiator clearly would not block waiting for the delegate to complete and yet the delegate would eventually start executing on the same thread. This is definitely a perversion of what we typically think of the term asychronous because in this scenario the operation blocks until the caller completes instead of the other way around.
Your question is too general. The Windows API has specific support for asynchronous I/O without using a thread, check the docs for ReadFile() for example. The lpOverlapped argument controls this. The ReadFileEx() function allows specifying an I/O completion callback. This is well covered by the .NET framework classes.
Calling a slow external API function is not covered by this mechanism, you need to spin up your own thread.
Yes, a Pool Thread is used. But that thread is not hanging around waiting for the external device. The thread is re-used and a(nother) thread is called upon when the I/O is completed.
See I/O Asynchronous Completion on MSDN.