Share via

Encore Presentation: What Every Dev Must Know About Multithreaded Apps

  • Article

 Back in August 2005 I wrote a MSDN article entitled What Every Dev Must Know About Multithreaded Apps, in which I describe the fundamentals of multi-threaded programming.   Although it was written over 10 years ago now, frankly, it is just as correct and relevant today. 

I discovered, however that the link to this article is now much more difficult to access.   MSDN articles over 8 years old are not directly accessible but you have to download the whole issue as a CHM file, remove the 'blocking' bit, and then extract the file.   Not super-hard, but not easy either.   To fix this I have done that for you and attached the resulting PDF file to this blog post.   Now you can simply open it to see this article.

To entice you to do just his, I will say that anyone who has to write ANY code that contains multiple threads needs to understand the content in this article.    Typically developer's start out thinking multi-threaded programming is 'easy' (after all it is 'just' running multiple sequential programs in parallel).   Then the find out just how difficult it is to insure that their programs run correctly in such an environment, and believe it is practically impossible.    Finally, after reading something like the article below they reach 'maturity' on the subject and realize it CAN be very dangerous but if you follow a set of simple rules CONSISTANTLY, you can do it reliably.    This article tries to get you to this mature state as quickly as possible.  

Vance

MultiThreading.pdf

Comments

  • Anonymous
    February 26, 2016
    Ah, I still remember back in 2005 when this article came out. As I was flipping through the glossy pages, I remember thinking that it was the single best MSDN article I had ever read, and that actually still holds true to this day. I still make every new dev under my command read it as mandatory introductory material. Vance, I hope you know what a positive impact you made to the industry.

  • Anonymous
    February 27, 2016
    The comment has been removed

  • Anonymous
    February 28, 2016
    @bruce Dawson.   I think we are basically in agreement.   You will note that the statement that you quote says that memory that is read only 'AFTER PUBLICATION' does not need a lock.    So that statement says that you need put publish, which is what you are saying.   Certainly a lock is a way of doing, this, but as the article on low lock techniques indicate, there are other ways as well (which again you indicate, so we are in agreement there as well).   Finally as a practical matter  this issue of publication of read-only data often handled for you.   For example, for static read-only variables there is a hidden lock in the runtime (to insure that the variable is only initialized once) and thus publication is handled.   But don't let me stop you from encouraging people to mark things volatile that involve any low-lock techniques, including those that are init-once.    It is a good practice.  

  • Anonymous
    February 29, 2016
    Vance, how did you get around the footer bit reading, “© 2007 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.”? I've been wanting to make some of my MSDN articles more accessible, which are also over 8 years old.