Hawaiʻi's Technology Community

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.


Views: 1332


You need to be a member of TechHui to add comments!

Join TechHui

Comment by Jason on April 10, 2011 at 3:46pm
Wow, I have to admit my ignorance.  I completely shut my mind off to C# simply because it's Microsoft.  Maybe I have to fire up windozzz in a VM and try it out one day.
Comment by Daniel Leuck on April 8, 2011 at 10:46am
@Dan, @Tim & @Cameron I agree. If I could write C# (especially v4+) on my Mac and run it on the JVM I would be a happy monkey. The new C# language level async support is very nice. Groovy makes programming the JVM more pleasant, but C# is still the ultimate evolution of C/Java family languages.
Comment by Daniel Nishimura on April 8, 2011 at 8:08am

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.

Comment by Daniel Nishimura on April 7, 2011 at 3:38pm

@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.  

Comment by Timothy Little on April 7, 2011 at 12:24pm
I'm no fan of M$ but I love C#.  If only the Mono guys could keep up, I could write C# on linux and be a happy programmer.
Comment by Cameron Souza on April 7, 2011 at 11:18am
I hate to admit it but that C# async framework is pretty damn cool. Maybe I will have to switch to the dark side...
Comment by Timothy Little on April 7, 2011 at 9:14am
Anders Hejlsberg (the father of C#) has been at again and designed a whole async framework to simplify the asynchronous workflow in the .NET environment.  It eliminates the hassle of debugging and event listeners in the async process.
Comment by Brian on April 6, 2011 at 12:34am

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.

Comment by Daniel Leuck on April 1, 2011 at 10:58am
Great post. I find that most programmers have a very poor understanding of concurrency including the relationship of application level threads to OS level threads to what can actually run concurrently (versus context switching) on their processors. Asynchronous IO is even less commonly understood despite having been around for a long time.


web design, web development, localization

© 2023   Created by Daniel Leuck.   Powered by

Badges  |  Report an Issue  |  Terms of Service