Question

What is the problem with having static variables (especially within functions) in multithreaded programs?

Thanks.

Answer 1

To pick an illustrative example at random, take an interface like asctime in the C library. The prototype looks like this:

 char *
 asctime(const struct tm *timeptr);

This implicitly must have some global buffer to store the characters in the char* returned. The most common and simple way to accomplish this would be something like:

 char *
 asctime(const struct tm *timeptr)
 {
    static char buf[MAX_SIZE];

    /* TODO: convert timeptr into string */

    return buf;
 }

This is totally broken in a multi-threaded environment, because buf will be at the same address for each call to asctime(). If two threads call asctime() at the same time, they run the risk of overwriting each other’s results. Implicit in the contract of asctime() is that the characters of the string will stick around until the next call to asctime(), and concurrent calls breaks this.

There are some language extensions that work around this particular problem in this particular example via thread-local storage (__thread,__declspec(thread)). I believe this idea made it into C++0x as the thread_local keyword.

Even so I would argue it’s a bad design decision to use it this way, for similar reasons as for why it’s bad to use global variables. Among other things, it may be thought of as a cleaner interface for the caller to maintain and provide this kind of state, rather than the callee. These are subjective arguments, however.