Building responsive and scalable applications
summary
Explains why synchronous I/O wastes threads and memory and shows concrete .NET fixes: use FileOptions.Asynchronous / ReadAsync/WriteAsync so the OS queues an IRP to the device driver and completion returns via I/O Completion Port into the thread pool instead of blocking stacks (user stack ≈1MB, kernel context ≈700–1,240 bytes). Demos show Task Manager with ~2,400 threads but only ~15% CPU and a 32-bit process crashing after ~1,500 threads. Recommends async everywhere and using ConfigureAwait(false) for library code to avoid deadlocks and improve scalability.
AI-written summary · about
chapters (9)
- 0:00Introduction and speaker bio
- 2:04Threads and reliability in OS design
- 19:54Thread overhead and scalability trade-offs
- 26:37Synchronous vs asynchronous I/O
- 41:16Async/await in .NET framework
- 48:10Fixing non-scalable server designs
- 51:46Application models and threading
- 59:42Deadlocks with GUI threads
- 1:01:50When to use configureAwait(false)
related talks
57mAsync programming in .NET: Best practices
55mAsync internals in .NET
59mAsynchronous Programming From The Ground Up
36mAsynchronous Programming on the .NET Platform
43mAsync vs Sync Programming
01h 00mCorrecting Common Async/Await Mistakes in .NET 8
01h 05mCorrecting Common Async/Await Mistakes in .NET 10
51mThe Need for Async