You can download my Auction code from my OneDrive:
Loading user information from Channel 9
Something went wrong getting user information from Channel 9
Loading user information from MSDN
Something went wrong getting user information from MSDN
Loading Visual Studio Achievements
Something went wrong getting the Visual Studio Achievements
You can download my Auction code from my OneDrive:
@djmarcus:You are correct that his is a problem but a lot fo work has been going on in this space. In my Power Threading library, my AsyncEnumerator class (along with C#'s iterator feature) allows you to have a synchronous programming model for doing asynchronous operations. This has been available for about 5 years now. It has received such support and success, that the .NET team at MS is adding very similar features to the next version of .NET and, the new features will support a deep call stack where you can initiate an async I/O at the bottom of the stack, return all the way up and have execution continue at the bottom of the logical stack when the I/O compeletes.
@gbrayut:Fibers are a pretty old technology. They were originally added to NT4 to ease porting of apps from other OSes to Windows NT. While SQL server has a fiber mode, the mode is usually used for benchmarking and not for real day to day running of the DB. There was an attempt in .NET 2 to add fibers to the CLR but the attempt failed due to separating state to give the impression of different fibers being different threads. Since fibers are not threads, they do not work like threads and using them can become quite difficult. This is why the CLR dropped the feature. Maybe on a platform where fibers are a 1st class citizens from the very beginning, they could work well.
You should be able to use processor groups today in .NET if you P/Invoke out to the native Windows APIs.The CLR team could wrap these for you but it is trivial for you to do it yourself. There are few machines with this many cores and Azure machines have no more than 8 cores so this would be very low priority for the CLR team.
I plan to revise my CLR vua C# book for the next version of .NET but I haven't started working on it yet. I'll probably start when it enters beta.
@serializable:I am not a WCF expert and I don't have time to examine your code. So I'm not sure if the WCF infrastructure is implemented poorly or if your code is not using the infrastructure correctly. I do know that the WCF team cared a lot about async operations and so the most likely problem is that your code is not using it correctly.
Rick may have some valid ideas here but he is also assuming that every web request results in a DB request which, in many web servers, is not true. I have written web sites where many requests are handled from memory or from cache or possibly from a store other than a DB. In this case, there are NOT lots of threads blocking on the DB and the threads can do other work. In addition, his only argument for not making things async is really just to simplify the programming model. He's not suggesting making things sync because your service is faster or uses less resources (both of which hurt scalability). He's suggestion is purely about simplifying the code. But with technologies like my Power Threading library's AsyncEnumerator, or with the new async/await feature being put into the next version of the .NET Fx, the programming model is much simpler than it has been in the past and so a simplified programming model is much less compelling of an argument.
All of Microsoft's hosting infrastructures -- ASP.NET, WCF, etc -- support asynchronous programming. The server gets a client request, the server makes a request to another server (like SQL) asynchronously, and the thread returns back to the thread pool. The hosting infrastructure knows NOT to send the response back to the client. When the server (SQL) responds, its response it put in the thread pool, another threadpool thread wakes up and your code processes the response and returns. When the thread returns to the pool this time, the hosting infrastructure DOES send the response to the client. Lookup how to implement your service asynchronously in whatever infrastrucutre is hosting you. For example, do a web search for "implementing ASP.NET Web form service asynchronously".
With each operation, you should always consider whether it is an I/O operation or a compute-bound operation. I/O operations do not use the CPU on the motherboard at all and so you scale them out using asynchronous I/O operations (Begin/End methods); do NOT use threads to perform I/O operations in parallel as this just wastes threads. Compute operations DO use the CPU on the motherboard and so you improve performance by having multiple threads (up to 1 thread per CPU in the machine) execute different pieces of the work concurrently. For compute operations, you can use QueueUserWorkItem (but this is fire & forget), or a delegate's BeginInvoke/EndInvoke methods, or create & start .NET 4's Task object. Delegate's BeginInvoke/EndInvoke allow you to have the same programming model for compute operations as you get for I/O operations.
I cover a lot of this in my CLR via C#, 3rd Edition book. My Windows via C/C++ also talks alot of threads and their overhead. The Windows Internals book by Mark Russinovich & David Solomon also has a lot of info in it. There is no such thing as a "managed thread". In managed code, you can ask Windows to create a thread. Again, my CLR via C#, 3rd Edition book goes into all of this in great detail.
Memory-mapped files are all about making file I/O look like RAM and so you can't work asynchronously with memory-mapped files. You are tradiing the simpler progrmaming model for reduced scalability (when acessing MMF data actaully results in I/O as opposed to accessing cached data in RAM).