Ive a question about this example: Asynchronous Client Socket .
It says that the operations are asynchronous and they ARE (beginxxx/endxxx are presented), but they use ManualResetEvent and if i understand the sample code correctly - such calls:
Receive(client);
receiveDone.WaitOne();
Will block the thread, they were called from. So that if i have an application with UI and i call that async socket code from main thread - application will freeze...Or am i wrong? Sorry, i expected to send/receive some commands over tcp asynchronously without freezing main thread. Will i have to call all the socket operations from that sample to avoid freezing?
Yes, this code is set up so that it will run synchronously. However, you can easily use the Beginxxx and Endxxx calls yourself rather than wrapping them as this (poor) example of asynchronous action is written.
For further clarification, the article does run each method asynchronously, but then blocks using blocker.WaitOne(); A better approach to something like this might be to have your beginconnect callback trigger a send, which will have its callback trigger a receive, etc
You could also use the TPL and take advantage of their ContinueWith functionality to do this. Then your code might even look cleaner :)
It would block the UI. The MSDN example does demonstrate asynchronousy, but very poorly. Its also primitive. Please look at this topic which I also just answered regarding different asynchronous programming models. I discuss quite a few and provide links for all of them with full examples.
Link: Need help to implement multithreading in C#
Related
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
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
I have a question regarding SignalR's official documentation - Hubs API Guide - .NET Client. In the section - How to establish a connection. It has been written the following thing:
The Start method executes asynchronously. To make sure that subsequent
lines of code don't execute until after the connection is established,
use await in an ASP.NET 4.5 asynchronous method or .Wait() in a
synchronous method. Don't use .Wait() in a WinRT client.
Does anyone know what is the specific reason not to call Wait()? Also, does also this apply when I have a WinRT client where I have a call with hubProxy.Invoke() to the server?
Thank you for your help!
From the comment:
There is nothing mentioned in relation to asynchronous or synchronous
code. Is the code WinRT asynchronous by default or there is something
else that I don't know or don't understand?
In a client-side UI app (including WinRT), there're at least two reason to not block:
avoid blocking the UI and keeping it fluent;
avoid the deadlocks as described in Stephen Cleary's blog, for cases when there's an await in the current chain of calls, on the upper stack frame;
The latter is especially important for WinRT, where asynchrony is pervasive. The whole WinRT framework has been designed to be "async all the way down", so it's very likely you'd create a deadlock if you use task.Wait or task.Result anywhere on the UI thread.
For a server-side ASP.NET app, there're also at least two reasons to not block:
blocking makes your web app less scalable, because the blocked thread could be serving other incoming HTTP requests.
the same deadlock scenario.
You may want to go through the list of links in async-await wiki for further reading materials.
According to this post:
How to write a scalable Tcp/Ip based server
jerrylvl states:
----------*
Processing
When you get the callback from the Begin call you made, it is very important to realise that the code in the callback will execute on the low-level IOCP thread. It is absolutely essential that you avoid lengthy operations in this callback. Using these threads for complex processing will kill your scalability just as effectively as using 'thread-per-connection'.
The suggested solution is to use the callback only to queue up a work item to process the incoming data, that will be executed on some other thread. Avoid any potentially blocking operations inside the callback so that the IOCP thread can return to its pool as quickly as possible. In .NET 4.0 I'd suggest the easiest solution is to spawn a Task, giving it a reference to the client socket and a copy of the first byte that was already read by the BeginReceive call. This task is then responsible for reading all data from the socket that represent the request you are processing, executing it, and then making a new BeginReceive call to queue the socket for IOCP once more. Pre .NET 4.0, you can use the ThreadPool, or create your own threaded work-queue implementation.
----------*
My question is how exactly would I be doing this in .Net 4.0? Could someone please provide me with a code example which would work well in a scalable environment?
Thanks!
My question was answered in more depth here: C# - When to use standard threads, ThreadPool, and TPL in a high-activity server
This goes into specifics on using each the TPL, ThreadPool, and standard threads to perform work items, and when to use each method.
I found a decent looking example of how to call a delegate asynchronously with a timeout... http://www.eggheadcafe.com/tutorials/aspnet/847c94bf-4b8d-4a66-9ae5-5b61f049019f/basics-make-any-method-c.aspx. In summary it uses WaitOne with a timeout to determine if the call does not return before the timeout expires.
I also know that you should have an EndInvoke to match each BeginInvoke.
So what happens if the wait timeout expires? We (presumably) DON'T want to call EndInvoke as that will block. The code can go on to do 'other things', but have we leaked anything? Is there some poor thread someplace blocked waiting for a return that's never going to happen? Have we leaked some memory where the result-that-will-never-return was going to be placed?
I think this post talks about it very well:
From the post:
You can't terminate an executing async delegate if it's not your thread, but you can if it is. If you use the common BeginInvoke type methods, you get a thread pool thread managed by the framework. If you use the Thread() class you get you own thread to manage, start, suspend, etc. as you like.
Developing asychronously requires that one decide who will manage the threads. The many different methods that execute asynchronously are using the ThreadPool threads behind the scenes.
Since you can't/shouldn't terminate a thread pool thread then you must design you code to communicate with the thread so that it can exit. The MSDN examples for the BackgroundWorker component demonstrates this kind of communication.
Sometimes your code may have the thread blocking waiting for IO. Here you would normally use a multiple object wait instead, waiting for IO or for a ManualResetEvent.
So in short, youll need to find a way to manage the threads yourself if there is a possibility of timing out and you want the thread to end.
You need to call EndInvoke().
Here is a link talking about what happens with EndInvoke():
Is EndInvoke() optional, sort-of optional, or definitely not optional?
Here is a link to the article in the accepted answer.
We had all been talking about the 'fire and forget' technique with asynchronous delegate invocation in various public forums. Many DevelopMentor instructors had written articles and example code showing the technique, and we had all described it in class. And of course it was in Don's book by then too. So when Microsoft eventually remembered to let the outside world know that this technique is not in fact legal, it was rather astonishing.
An MSDN link on the asynchronous pattern.
You will leak the resources held by the thread. There will be various bits of .NET remoting plumbing objects like the AsyncResult. Several unmanaged handles associated with the thread. All peanuts compared to the one megabyte of virtual memory address space you'll leak, held by the thread stack.
You cannot abort the thread in any way, the leak is permanent. When you have to deal with badly behaving code like this, your only good resource is to run it in a separate process so you can get Windows to clean up the shrapnel when you shoot the process in the head with Process.Kill(). Even that is not guaranteed, these kind of freezes tend to be associated with misbehaving device drivers. Process.Kill won't terminate a device driver thread. Easy to see: trying to abort the process with Taskmgr.exe will leave it running with one Handle. You have some hope if that doesn't happen.