Tuesday, September 20, 2005

Thoughts on Threading

So this week I've been thinking a lot about threading.

Specifically I've been thinking about large, complex multithreaded servers that are difficult to write, to test, and most importantly to modify later on, especially if you are not the person who actually designed and implemented them in the first place.

Among the better papers I've seen on the subject is "Reasoning about SMP in FreeBSD", by Jeffrey Hsu, who did a lot of work on locking the FreeBSD network stack as part of it's SMP project. Interestingly enough, Hsu is now working on DragonFlyBSD, which has taken a rather different approach to its multithreading than FreeBSD did. Makes you wonder if the more traditional techniques (fine grained mutexing, a-la the Solaris kernel) used in FreeBSD are really the right way to go...

Go read the paper, it's good.

Anyway, the big idea of that paper is that to effectively think about a multithreaded system you really need to understand what it's doing. You can't effectively add locking to one part of the system without totally understanding all the interactions it has with the rest of the system. You really need to see the big picture in order to know how to make the individual decisions.

I've been having trouble seeing the big picture, that's the problem.

1 comment:

  1. This is why event driven servers are good. They limit the number of threads.
    Recently I've been working on combining threads with an event driven server, and that can be tricky. I think most server problems could broken down into a producer/consumer queue of actions and n constant worker threads to perform the action.
    IMHO this is much simpler than one thread per action, although it isn't totally fool proof. For instance I have have one known potential deadlock situation that is particularily tricky to work around.
    I do think you are right. You can't look at a threaded system in isolation like an object. You have to consider all the interactions in the system.