Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I received an offer for a job where approximately 80% of my work will be multi-threading related. My multi-threading experience is limited to my undergrad (UNIX programming course) and two instances where I used a thread pool and a background worker instance.

I am concerned (as is my future employer) about my lack of multi-threading experience. Aside from reading the famous Albahari threading tutorials, what's the best way to learn threading, given that I have maybe a month before I start?

What I would like to do is improve my multi-threading/concurrency skills as much as possible before I actually start. I don't know if or how well this is possible.

share|improve this question

closed as primarily opinion-based by gnat, GlenH7, thorsten müller, MichaelT, Kilian Foth Oct 6 '13 at 14:12

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

9 Answers 9

up vote 4 down vote accepted

In my experience, the most productive trick was playing with code while studying.

Grab all the threading code examples and "toy programs" from the tutorial you're studying, put them in your favorite IDE and start compiling-running-editing-debugging-changing-compiling-etc. If you find related examples in the web, grab them too.

To me, studying tutorials combined with playing with code examples was about 4-5 times more productive than without :)

share|improve this answer

Firstly, your new employer obviously thinks you will cope or they wouldn't have made you the offer. Hiring somebody is expensive & getting it wrong is even more expensive.

Does your employer have a senior developer that you could telephone & ask for advice? The senior dev should know better what you should be focusing on. This also shows to your new employer that you are serious about making sure you are productive as quickly as you can be which is a good impression to give.

Otherwise, nobody expects a new hire to be effective from day one so when you arrive focus on learning the existing codebase and write short little applications to test the concepts you are seeing. You can extend this into your own freetime programming as well if you like because writing effective threaded applications is both fun & challenging.

Good luck

share|improve this answer
I know that they think I can cope. I think so too. My goal with this question is to hit the ground running if I can; I'm just not sure how, other than coding small proof-of-concept apps. –  ashes999 Aug 26 '11 at 3:17

If you've got a month you probably don't have time to become a threading expert, but unless you're going to be the only developer there then don't worry too much about being one. The other devs will be there to help, just make sure you know the basics concepts of threading, what pitfalls you're potentially going to face and write a few quick applications to get that muscle memory developed and then be ready to ask as many questions as it takes to get that skill beefed up over the first few months.

I'd really recommend just hitting wiki, following every link, do some searches about multithreading theory and concurrency. It's a tricky topic, but it's learnable and a month will give you enough knowledge that you can get in and understand what's going on under the hood.

share|improve this answer
Hitting which wiki? –  ashes999 Aug 26 '11 at 17:08
msdn, I'm assuming... –  Morgan Herlocker Aug 26 '11 at 17:50
Proper wikipedia, any dedicated programming based ones, any knowledge bases that are open for access. Wikipedia might be a bit light on detailed information at times but it certainly points to a lot of good stuff. –  Nicholas Smith Aug 26 '11 at 22:12

I'd take a look at the MSDN threading tutorial.

Then pick up a copy of CLR via C#, he has excellent coverage of threading in C# (and plenty more besides).

share|improve this answer

Jon Skeet's tutorial on threading really helped me. I still refer back to it from time to time:


share|improve this answer
Excellent link, thanks. –  ashes999 Aug 26 '11 at 17:08

You should be working.

Want to learn threading fast? Stop reading about it and start writing multithreaded programs. You should be reading tutorials and articles to help answer a specific question about what you are currently doing. Not as an excercise by themselves. You wont take as much away from anything you read without having the experience to understand the implicit context in the articles.

Write a program where a bunch of threads compete for finite resources. Go write a basic job system. As you get stuck come as questions or look up the answers. This means you will have the experience to know what questions to ask and get more out of the answers.

share|improve this answer
While you're right about learning-by-doing, the problem with multi-threaded programming is that there are a lot of things you can do wrong that won't rear their ugly heads until you put it in production and put some load on it. Even then, it might only break every few weeks or months. I think on this particular topic, making sure you're familiar with the fundamentals and the "gotcha's" is a really good idea before trying to write production code. –  Scott Whitlock Aug 26 '11 at 14:19
Depends on your level of knowledge. You wont understand the importance of the "gotchas" if you've never written a multithreaded app. I never said don't read. I said write first. Good point though. –  Bo Buchanan Aug 26 '11 at 14:28
Compromise: read the barebone basics; code a little; read a little more; code a little more; repeat. –  Morgan Herlocker Aug 26 '11 at 17:55
@ironcode: I'd advise a more reactive approach to reading. Start writing your program. Get stuck, then go figure out how to get unstuck. Repeat. When you think you are done with the program you wrote then go look for documentation on what type of program you wrote and the techniques you used. You now have the experience necessary to start to understand the documentation about those techniques. Take what you learned from your reading. Throw out the original program and do it again using what you've learned. Repeat the whole process if you changed the second iteration significantly. –  Bo Buchanan Aug 26 '11 at 18:07
@bo The problem with ignorance is, by definition, you don't know that you're lacking some key necessary knowledge. I think the "do it first, then look for help" approach works in some cases, but for something complex like this, you need a decent understanding first. But I agree, it makes more sense when you have something real to apply it to. What worked for me was to read first, then do something (referring back as necessary), then re-read, at which point things made a lot more sense. –  Joel C Aug 26 '11 at 19:31

I think the most comprehensive resource I've found on Multi-threaded programming for Windows is Joe Duffy's Concurrent Programming on Windows. It's very comprehensive. If you're only concerned with C#, there are a couple of chapters you can flip through quickly, which is good because it's a big book.

I highly recommend it. I also don't think it's something you want to try to learn "quickly". There are very complicated aspects to multi-threaded programming, and if you try to avoid understanding them in detail, you'll just create a lot of problems for yourself in the future (or the next poor person who has to maintain it).

share|improve this answer

Write some code using AutoResetEvents http://msdn.microsoft.com/en-us/library/system.threading.autoresetevent.aspx

And practice using a DispatcherTimer to update the UI. http://msdn.microsoft.com/en-us/library/system.windows.threading.dispatchertimer.aspx

share|improve this answer
These two are very limited in scope. Having read the famous Albahari tutorial, I can honestly say these represent a very small percentage of the big field of multi-threading. –  ashes999 Aug 26 '11 at 17:07
@ashes999 I read from your post that you haven't programmed any theading application at all. Since you are a self described noob, I suggested some easy starting points. –  iterationx Aug 26 '11 at 17:09
I guess you missed that part where I mentioned using a thread pool and a background worker. Those were simple cases, true, but they were real multi-threading experience. –  ashes999 Aug 26 '11 at 20:00
@ashes999 I meant in a Windows environment using C#. –  iterationx Aug 26 '11 at 20:01
one was a .NET 2.0 windows form app, the other was a Silverlight game. –  ashes999 Aug 26 '11 at 20:02

Keep an eye on the future of .net-

The Past, Present and Future of Parallelizing .NET Applications

Though I am no expert in multithreading in .net, but I found this article very much useful to have a future vision of .net mutithreading. And it reminds me the famous saying-

No code is better than no code.

This new link about .net 4.5 may come helpful. Though it is only in preview stage-

What’s New For Parallelism in .NET 4.5

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.