Concurrency, Part 15 - Wrapping it all up.

Nice Series on Concurrency

Better Half — Thu, 10 Mar 2005 21:38:00 GMT

Larry Osterman's Concurrency Series This is the last post in a series about concurrent programming....

re: Concurrency, Part 15 - Wrapping it all up.

JD — Thu, 10 Mar 2005 18:39:00 GMT

Can we release this as a pocket bible for concurrency? :)

Though at current stage, I don't have to worry about concurrency, but it was an insightful series. Which series is coming up next?

JD

re: Concurrency, Part 15 - Wrapping it all up.

B.Y. — Thu, 10 Mar 2005 18:42:00 GMT

Well, here's an app design question somewhat related to concurrency. I worked on a video streaming application that handles up to 16 video streams (but in most cases the number of video streams is 4 or 8), and for each video stream, there're the following major tasks:

*receive packets from the network
*save video to disk
*decode (bottleneck)
*display (bottleneck)

How would you arrange things (threads and whatever) in this application for maximum performance ?

re: Concurrency, Part 15 - Wrapping it all up.

Capt. Jean-Luc Pikachu — Thu, 10 Mar 2005 19:12:00 GMT

Wasn't there a Part 0? I think it was the spot the bug one w/ the 2 threads for copying a file or something?

re: Concurrency, Part 15 - Wrapping it all up.

Drew — Thu, 10 Mar 2005 21:47:00 GMT

I was almost expecting "the future of concurrency" and an intro to Cw (that's supposed to be an omega) after the CLR post. This was good. I enjoyed it and it left me wanting more. Always leave 'em wanting more.
Thanks, Larry.

re: Concurrency, Part 15 - Wrapping it all up.

Eric Lippert — Wed, 16 Mar 2005 18:17:00 GMT

> How would you arrange things (threads and whatever) in this application for maximum performance

Let me answer that question with another question: why is MAXIMUM performance important to you? Isn't your goal to achieve ACCEPTABLE performance?

Spending time and money to make code faster than it needs to be is stealing time and money from robustness, security, bug fixing, more feature work, and plain old returning unspent cash to shareholders.

To actually answer your question -- if you want MAXIMUM performance, don't fool around with the NT thread scheduler. It was designed to work well for general-purpose application programming, on machines being used for everything from serving web pages to playing nethack. You're going to waste entire microseconds in badly timed context switches.

If you want MAXIMUM performace, write your own custom thread scheduler specifically tailored to your task -- preferably in tightly optimized assembly. A deep knowledge of fibers will come in handy. Good luck!

Another year, another post

Larry Osterman's WebLog — Wed, 15 Mar 2006 20:21:19 GMT

Well, this year I didn't miss the anniversary of my first blog post.
I still can't quite believe it's...