13

I am currently a C# developer with a pretty shaky understanding of threading.

Both of these links have been suggested in other posts:

http://www.yoda.arachsys.com/csharp/threads/

http://www.albahari.com/threading/

Should I go back to basics and maybe look at some computer science texts on the subject?

I really feel that if I jump in and use the c# libraries I won't really have a solid foundation of knowledge to build on. I think I need to learn this subject from scratch like a com sci student, then use the C# libraries.

Can anyone suggest an approach to learning threading, maybe some links and or project ideas?

Thanks in advance!

Edit, thanks for all the replies. Some people have mentioned that a book might be a good idea, can anyone suggest one? I'd prefer something language agnostic. Does anyone know what class would this stuff be covered in in a Computer Science degree? I'm trying to google for some free online notes and assignments.

Improve this question
2
  • I don't know if this helps but this is a simple tutorial that I wrote in VB.Net a little while back that explains the basic concept of threading. You should be able to convert it to C# pretty easily. chrishaas.wordpress.com/2009/06/25/…
    – Chris Haas
    May 11, 2011 at 21:00
  • I'm strongly tempted to suggest writing a multithreaded GUI, on the grounds that it would teach the limits of what it is possible to do with threads and remain sane. But that wouldn't be constructive, so I'll let it ride as a comment, not an answer… :-)
    – Donal Fellows
    May 12, 2011 at 13:11

7 Answers 7

Reset to default
3

Write a multi-threaded web server. You will learn a TON. And not just about threading.

Improve this answer
0
4

The producer-consumer problem is a classic example, and it helps you to understand not only threading, but processor scheduling (it can be demonstrated using fork() for child processes as opposed to threads) and how your programs interact with the operating system behind the scenes.

Here's a rundown of the important things you should understand regarding threading/forking 1. How the operating system schedules tasks (round robin algorithm for example) 2. Resource Locking (If multiple threads are utilizing the same resource, you don't want them to be accessing them at the same time -- BAD THINGS HAPPEN)

Here's a wiki article on this classic problem: http://en.wikipedia.org/wiki/Producer-consumer_problem

Basically, create a "Producer" who spawns threads of "Consumers". The producer produces a "resource", and the consumers consume it. Put it in a loop and watch what happens (you'll be surprised that eventually the consumers will consume more resources then are available due to unsynchronized methods).

Improve this answer
1
  • Interesting, seems I setup this pattern without realizing it while creating a threaded windows service. Your description was perfect. Good one to know, this would almost be marked as an answer on my open question.
    – Tony
    Oct 10, 2014 at 2:36
2

Pick one of the classic highly parallel problems. You might find it more interesting to pick one with super-linear speedup.

Consider searching through an unsorted and unindexed list. This problem is trivially parallel. First implement a single threaded search, then a naive parallel search. Implement work-stealing. Generate some random data sets and run all three versions on the same data sets. Calculate the speedup.

Improve this answer
0

I don't think a textbook is the next best step. A project is the way to go. It should be something you're excited about.

The first time I did threading I was improving the performance of a web crawler. You can crawl a lot faster if you aren't doing all your network IO in serial. This is a great project to start with because you can approach it quite a few ways, but it's not nearly as complicated as, say, multithreaded GUI programming. It also doesn't require much specialized skill (for example, heavy computational stuff).

So, figure out some info to scrape and start hacking. It shouldn't take you long to get something going, it will be a gentle introduction.

Improve this answer
2
  • I agree with a project, but network I/O is not a good use case for threads. Non-blocking I/O is more efficient, uses less resources, and suffers from fewer race conditions and corner cases than the same problem solved with threads. Part of learning to be a good parallel programmer is recognizing when threads aren't ideal.
    – Ben Voigt
    May 11, 2011 at 21:34
  • You may very well be right, the experience that I was referring to was some very basic Python web scraping where I added about 8 lines of code to make it multithreaded. I doubt it would have been that easy to do it async with the existing code, but I would love to know if/how I'm wrong. I think part of learning to be a good parallel programmer might be to have lots of experience under your belt, good and bad :)
    – Henry
    May 11, 2011 at 22:03
0

Model a simple Spy vs. Spy app.

Each spy runs on a separate thread.

Each spy can inflict damage on the other spy, but not directly.

Each spy can steal valuable resources from the other spy, but not directly.

Both spies have a limited pool of resources at their disposal, and must share them. Only one spy can use any given resource at a time.

Improve this answer
0

Off the top of my head: The 4th Edition of Bruce Eckel's Book "Thinking in Java" has a very long chapter on threading ( >100 pages - almost a little book in itself). I have read older editions of the book, and so did not read this chapter; but I remember one of his blog posts (or the release notes of his book), where he claims that writing this was very hard and in the end it was a real accomplishment for him. Check it out...

Aside from this, there is this 2.5 hour video course on this commercial training site, but you can get a free trial (must leave credit card data; so don't forget to unsubscribe)

http://www.pluralsight-training.net/microsoft/olt/Course/Toc.aspx?n=clr-threading

Improve this answer
0

Should I go back to basics and maybe look at some computer science texts on the subject?

That's always a good choice and I would recommend that you pick up a good threading book in order to familiarize yourself with threading. I learned multithreading in Java and the knowledge translated pretty easily into C#.

If you want a practical example, then I would recommend you try the dining philosopher problem.

You need to learn several things when you're getting into multithreading:

  1. The different ways to synchronize (semaphore, mutex, etc.)
  2. Atomic operations (in C# it's done via Interlocked for operations that are not atomic by default).
  3. Lock-free concurrent programming.
  4. Wait-free concurrent programming.
  5. Threads, ThreadPools, BackgroundWorkers, etc.

I can't think of other things at the moment. The Albahari tutorial looks really good!

Improve this answer
4
  • Unfortunately, dining philosophers is not a useful problem. It's intended to be a demonstration of race conditions, but whether the deadlock actually occurs is subject to the vagaries of the system scheduler, other tasks, hardware interrupts... in short it's completely undeterministic, and this I think it's not a good place to start learning.
    – Ben Voigt
    May 11, 2011 at 21:29
  • 1
    @Ben Voigt, I would agree that the dining philosophers problem is non-deterministic, but I'd say that the majority of threading problems aren't deterministic either. When I took a concurrent programming class it was one of the first exercises we did, now I'm not claiming that the teacher was necessarily right, but he was certainly one of the best teachers I've had and his ability to explain and teach concurrency was superb. The DPP demonstrates just one type of concurrency issue: deadlocking. The OP should also look into race conditions, the ABA problem, and so on.
    – Kiril
    May 11, 2011 at 23:06
  • @Lirik: Sure, understand the dining philosophers problem. But I wouldn't implement it. Writing wrong code can become a hard habit to break.
    – Ben Voigt
    May 11, 2011 at 23:35
  • @Ben Voigt, sorry, I must be missing something: the point of the dining philosophers problem is to write a program that does not deadlock, so how would solving the DPP require the writing of "wrong code"?
    – Kiril
    May 11, 2011 at 23:53

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