|You can find a lot of thread classes and patterns on the Web, but you won't find one which fits all your needs.
That, at least, is what happened to me.
Learnt a lot along the way, though. Here goes some of it.
The main issue is synchronization. There are many shapes and flavors, but the general idea is, the least you serialize access to stuff, the better off you are, both in respect to performance and to the risk of deadlocks.
Then again, there are several kinds of multithreading models.
The simplest one, is the 'shoot and forget' kind: print spooling is an example. You start a process running, and it will be done when it's done. Synchronization here is easy: just don't.
Then there are all the foreman/workers models, when one object (the foreman) lives in a thread, and sends jobs to one or more 'worker' objects, which execute those jobs on separate threads. Here, you can use any kind of mutex (in the broad sense of the term, which includes critical sections and the
PostThreadMessage() function), and the appropiate one depends on how long each job will take, and how long the program will be 'on the air'. A Windows service must be more robust than a batch process that runs just for a few minutes.
You avoid deadlocks by locking only the message queue between the foreman and each worker (each worker has one), and for the shortest period of time. Particularly, the worker thread should lock the queue only while it's popping a job, and NOT while it's executing the job. In this design, there are no shared resources among threads but the message queue between a worker and its foreman. The Windows API
PostThreadMessage() works like that.
An alternative to this model holds only one message queue for all workers. This one is practical if jobs are rather lengthy: the key question is, how often will a worker wait on the shared message queue while another worker is popping a job.
Some other resources might be shared among threads: think about an error log, if you use a text file for error logging. In that case, you need a OS-level lock (such as a named mutex, in Windows) while you're working with that file. Since errors should be relatively rare, you can get away with this; but, if you're logging, let's say, results, a more robust approach shall be needed. A database, for example.
Designing a multithreaded job
It all begins with a piece of paper, divided in several columns:
- User: Represents the user thread.
- Foreman: Gets a 'start working' message from the user thread, generates 'jobs' and divides them among the workers (or posts them to a common queue, and each available worker will take them from there). Might report progress to the user's thread.
- Workers: This column is usually divided in three: A, B, and Murphy. A and B take turns trying to work, Murphy will try to lock an object whenever it's needed by another thread. As you might have guessed, at design time Murphy is my closest collaborator.
The workers will usually not report progress, but set some state which can be queried by the foreman.
I've been using threads whenever suitable for a few years now, and haven't met a deadlock yet (I fell into a database deadlock once, but that's a totally different story). Performance is usually satisfactory, despite the cost of thread switches: those can be helped by using a LIFO approach for worker threads, if you've got several of them. Debugging is not that much of an issue, since I unit-test as much as possible (not everything, to be honest), and I keep the bussiness logic apart from the threading code: I also like traces better than breakpoints, anyway.
The bottom line: I've heard people say that multithreading in C++ is hard, error-prone and difficult. Well, those reports, in my humble opinion, are exaggerated.
It's just a tool; use it the right way for the right job, and you'll get the right result.