Encore Presentation: What Every Dev Must Know About Multithreaded Apps

 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.  



Comments (4)
  1. Daniel Stolt says:

    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.

  2. Bruce Dawson says:

    Good read, but this claim is not true:

    “memory that is read-only after publication does not need a lock because any invariants

    associated with it must hold for the rest of the program (since the value does not change).”

    After the memory is published there is no guarantee that the published changes are yet visible to other threads. Only by acquiring a lock (or a read-acquire read) can another thread be certain that it is seeing the final values. Realistically this risk only occurs for “a while” after the changes are published, since caches tend to get flushed and synchronized in a timely manner, but it is wrong.

    If the data is published before the other threads are created or if other locks are grabbed by the readers first then correctness can probably be proven.

    As a general rule, sharing data between threads requires an explicit publishing step and an explicit acquiring step – the acquiring step must happen at least once on each reader thread after the last publish by a writing thread. Locks do this automatically.

    One way of thinking of it is that if the readers don't acquire a lock then how do they 'know' that the data has been published?

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

  4. Atif Aziz says:

    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.

Comments are closed.

Skip to main content