Pablo Aliskevicius - Professional Profile

1. It's a leak. Sometimes, somewhere it's allocated, but it is not always released.
2. It's dangling. Since it is always is in scope, and it is not always allocated, sometimes it dangles. Even if 98% of the times it is released, it is immediately set to NULL.
3. Both.

• The coder uses specs as a baking recipe: the code should be a translation of the specs into a language the compiler understands.
• The programmer is an artist: specs are just another source of inspiration.

Specs written for the coder, on the contrary, must be painfully detailed. Most QA testers I've met seem to love these, but sooner or later a real customer complains that the program does not do something obvious - and faces the answer 'it works exactly as specified'.

What is your experience?
What kind of specs do you find most useful? How strictly does your code match those specs?
I'd really like to hear.

DWORD WINAPI ThreadProc(LPVOID pX)
{
    // Cast passed pointer to what it really is.
    if (pX != NULL)
    {
        X *realPointer = reinterpret_cast<x> pX;
        // Initialize COM
        // Generate message pump
        ::PeekMessage(whatever);
        // Connect to database
        while (!done)
        {
            ::GetMessage(....)
            switch(msg.uMsg)
            {
                case WM_COMMAND: // Cast LPARAM to pointer to a Job, execute that job.
                    realPointer->ExecuteCommand(msg.lParam);
                    break;
                case WM_QUIT:
                    done = true;
                    break;
 
            }
        } // while
        SetEvent(realPointer->reallyDone);
    } // if, scope for casted pointer.
    return 0;
}

The word 'legacy' means different things to different people. To me, it brings associations of hounted manors...

A few weeks ago, I found myself writing a program (Windows service, listens for events and passes them on) which had to use a legacy DLL while providing decent performance.
The first thing that came to mind was multithreading. It didn't last.

That DLL does not support multithreading: it has lots of global variables, which, if you're old enough, you may remember were deemed 'efficient' by C programmers, since they don't take stack space; in the days of DOS, with 32Kb stack, that was meaningful.
Refactoring the DLL was not an option: lots of work and lots of testing, with the prospect of breaking something, and under an extremely tight budget; and someone else is in charge of maintenance of that DLL.

Then I remembered having seen somewhere threads referred to as 'lightweight processes' (in a book about Windows 95 programming), so I figured, can processes do the task?

Fortunately, the DLL exposes only one function, which performs a rather lengthy batch operation.

The solution was like this:

I wrote an EXE which takes parameters somehow (it reads them from a SQL stored procedure, but the command line or a text file could have been used as well), and passes them to the DLL.
The service manages a process pool, whose maximum size depends on the number of CPUS in the machine.
When an event is detected, it's added to the SQL table which the aforementioned procedure reads from; one of the server processes is selected from the pool; if it's necessary, CreateProcess() is called on the executable (unless it's already running).

It might seem a bit crude, but it gives above-decent performance, the service itself keeps a tiny footprint (it has no code that really 'does' stuff), and any crashes in the legacy DLL (it didn't happen yet, but it might) don't crash the service.

Also, debugging a 'regular process' (single threaded) is easier than debugging a multi-threaded service.

The moral? Sometimes heavyweight is the right weight. As much as I like threads, there are other tools available, and they should not be forgotten.

 

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:

1. User: Represents the user thread.
   
2. 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.
   
3. 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.
   

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.