Be aware that the asynchronous methods in .NET don't necessarily use a thread. For quick and dirtly example of how this is true for socket programming, let's say, check out this blog post by Ian Griffiths. It is important to understand whether a thread is *really* being allocated or if it just seems that way. An asynchronous call != new thread. The blog post above shows a quick and dirty server that handles anywhere from 100-1000 incoming connections, yet only uses ten threads.

I think the emphasis that should be put on what your teacher says is that no "blocking" code should be in an asynchronous process. I don't think the biggest worry is about allocating too many threads though. .NET can usually handle all that stuff (and there is a set maximum limit of threads in the thread pool). If your requests take longer than normal than you will see you response times tank. The bigger concern with blocking code is race conditions and deadlock.

Let's say that request #1 locks resource #2. Then request #2 locks resource #1. Well, if request #1 then tries to lock resource #1 before releasing resource #2, then request #1 will be waiting for request #2 to unlock its resource. However, request #2 is waiting for request #1 to unlock its resource, and hence, a deadlock has occured.

Is there a specific example of blocking code that you are worried about? The biggest "blocking code" to worry about are locks that are put in place for multithreaded safety.