A long time ago, during the time of green screen computers, if a network server wanted to process a request from a client, it would have to wait for the I/O (Input/Output) process on the incoming data packets to complete and then process the data before accepting another request from a client. What if it took 1 second to complete a single request and there were 60 clients simultaneously sending requests? If I remember my 1st grade math correctly, that would take a minute to process all those requests. That's a decade in the digital world!
Multithreading to the rescue?
You're probably thinking, "Well we've come a long way and now I have a quad-core i7 processor with Intel© Turbo Boost Technology and Intel© Hyper-Threading Technology. I'll just spawn 60 threads and have my server super multithreaded!". Well my friend, only 4 threads can truly run in parallel on your i7 quad-core (well... 8 threads if you have that cool Hyper-Threading Technology turned on). The other 52 threads will have to share time on the cores (this is called context-switching). Context-switching takes time in addition to each thread reserving a block of memory called stack memory (usually around 1MB to 2MB). Threads are so needy. You can't have too many needy threads running around on your CPU, right? Not very scalable at all!
So what's cool?
Asynchronous I/O! I/O is normally much slower than processing data on the CPU and I/O mostly runs on a device, such as a hard drive or network card. Asynchronous I/O is implemented in the operating system kernel (For example: epoll or kqueue in linux). An event occurs on the operating system when an I/O process completes that lets the system know when data is ready for processing. The data can then be processed while the next I/O executes. This allows full utilization without the expense of additional resources. This equates to... wait for it... SCALABILITY!
Still not buying it?
Are you a fan of node.js? The nginx webserver? How about Twisted or Tornado in Python? EventMachine in Ruby? Java NIO (Netty, Grizzly)? If you are a fan of any of these frameworks, then you are definitely a fan of asynchronous IO because it is what drives each framework.
In conclusion
OK OK multithreading is still cool. Some frameworks allow you to configure a threadpool to at least utilize the number of cores on the CPU.
Comment
Here's an interesting article from the Twitter engineering blogs about how migrating from ruby on rails, which is synchronous in nature, to a custom ASIO server improved their search performance drastically.
http://engineering.twitter.com/2011/04/twitter-search-is-now-3x-fas...
@Brian - I agree writing async code may get complex, but the same also goes for multithreading programming and dealing with synchronization issues.
@Tim & @Cameron - I'm on board with both of you... Yay for C#, Nay for M$. It is too bad that Mono is always a version or two behind. They also won't support WPF which is another downer.
While the examples they mention are rather dated, I think Lauer & Needham got this right in their 1978 paper. Skip to page 12 if you don't want to read the whole thing.
Stateless & Asynch IO is fantastic and I'm a huge fan of nginx/et al. There are still many places where the programmatic complexity of writing asynch/state-safe code is not really justified. Right tool for the job.
© 2023 Created by Daniel Leuck.
Powered by
You need to be a member of TechHui to add comments!
Join TechHui