Threaded programming - ties to asynchronous programming? Useful for web apps? [closed]_问答_开发者

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably ans开发者_开发问答wered in its current form. For help clarifying this question so that it can be reopened, visit the help center. Closed 11 years ago.

Aside from AJAX, I don't know much about asynchronous programming, and certainly nothing about threads aside from the basic idea behind them. So, needless to say, I was a bit perplexed when I saw in a MSDN blog that the newest version of Visual Studio/C# will have asynchrony baked into the language itself.

So, as a beginner to the whole C#/MVC world, should I start learning about threads? Would they be useful to me? Are threads and asynchronous programming similar?

The first thing you should learn is that asynchrony and threading are two different things. Threading is about concurrency, not about asynchrony. More specifically: concurrency is a strategy for managing asynchrony.

We need to manage asynchrony because computer programs increasingly are manipulating high latency data sources. That is, the gap between when you need to get the information and when the information becomes available to the processor is large enough that the processor ought to be doing something else in that time. The source of that latency could be anything -- it could be that another thread is doing the work and the current thread is waiting. It could be that another computer in this cluster is doing the work, or it could be that you're waiting for a disk to spin or data to arrive over a network, or whatever. Latency is everywhere these days.

The typical way to deal with this is to synchronously wait for the information to become available; that is, block. What if you don't want to stall your processor waiting for the information? You need to wait asynchronously. That is, do something else while you're waiting.

Threads are one solution to this, but they're not a great solution. Neither blocking nor doing a lot of work on the UI thread is a good idea, and dealing with threading in general makes you have to reason globally about your program in order to avoid deadlocks. Another solution is to break up the work into tiny little pieces; as soon as one piece of work has to wait, you queue its continuation up, go do something else, and come back to it later, all on the same thread. The async work that will be done in the next version of C# uses a combination of various techniques to achieve better support for asynchrony without blocking the UI.

If this subject interests you, I have an article on it for beginners in October 2011's issue of MSDN magazine which you can read online here. My colleagues Mads and Stephen also have articles that go into more depth.

Threads are one of the OS features that enable asynchronous operation. You can program directly with threads, but the upcoming C# language features are at a higher level of abstraction and likely easier to deal with without causing concurrency bugs.

Concurrency is useful if you're either modelling a concurrent problem domain, or when you need to respond to requests (e.g. a user clicking a button) before the action the request initiates completes. A canonical example would be a file copy operation in a file manager - the copy takes a long time, but you need to tell the user about the progress of the operation, and the rest of the file manager needs to remain responsive. So, the file copy isn't processed synchronously with the user request - you finish responding to the drag-and-drop itself before the file copy completes, and finish the rest of it in a separate thread.

This is also what the "asynchronous" in AJAX means. If XHRs were synchronous, it would mean the HTTP request would have to return with data before the browser could process further user input, and the browser would "freeze".

In web development, an example would be generating a complex report over a database. Instead of having the report result page load for two minutes, you could generate the report in the background, and show a page with a list of report requests where the user can download the report once it's finished.

No... you don't need to learn multi-therading. If you're working with web applications (ASP.NET, MVC, etc) then you generally don't have to use multi-threading yourself, although your application may implicitly run in a multi-threaded environmet. Multi-therading is rarely (if ever) used in web applications, rather, it's used in desktop applications, services and libraries built (in this case) with C#.