Click here to Skip to main content
15,868,141 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
To make sure that I write thread-safe code and to check the thread safety of my code in more than a dozen projects, I would like to disallow use of static variables in most of my source files. However, I might still like to be able to use static functions in case two files have functions with the same name.

Disallowing static use as accomplished using

#define static STATIC_DATA_IS_NOT_THREAD_SAFE

However, I'm not sure how to allow static functions...

Could you suggest an alternative?
The one I can think of is writing a program to read all of my code and logging any files where static appears without an open parenthesis.
Alternatively, I can forbid static altogether and wrap my static functions in namespaces based on the source file name.
Posted
Updated 21-Sep-10 19:00pm
v2

1 solution

Turning the question back around...

Why are you using file/module level static functions and data in the first place? If you want file/module level functions and data then use an anonymous namespace.

Removing statics won't make your code thread safe BTW - any form of shared data or aliasing of variables can sink you unless you're very careful.

Cheers,

Ash

PS in response to the comment below...

You don't need to name your namepaces if you're just using them to restrict access to other objects in the same file. If you do:

namespace
{
    bool do_something_groovy_that_was_static()
    {
        //...
    }
}


then only things in the same file as do_something_groovy_that_was_static will be able to call it.

As far as multithreading the only code that's absolutely safe to use is something that doesn't use anything not directly created in that code. So local variables only and only use functions with no side effects. These days you can get away with memory allocation with multithreaded allocators but I wouldn't stick my neck out much further.

Globals are one of the roots of all mulithreading evils - make sure that any global resources you use are synchronised properly. Wrap them up in a class if you have to but make sure nothing can get at them without acquiring a lock of some sort. The same goes for statics as well, whether in functions, classes or files.

One suggestion is that if you use fairly strict test driven development (which, as a side effect, removes things like globals and statics as it's almost impossible to write unit tests for code that depends on these things) then your code will be a lot more thread safe. From my limited experience that seems to work so it might be a route to follow in future.
 
Share this answer
 
v2
Comments
T2102 22-Sep-10 3:08am    
My statics typically were constant static arrays such as constants utilized for statistical functions, counters, or to cache the inputs and results from the last few calls to a particularly expensive function where the probability of reuse elsewhere is high. I am modifying my static functions to namespaces named after the file name for clarity for me.

Thanks for the input on aliasing and globals. I will try to address global variable next.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900