Static Members Across Libraries (windows Dll Vs. Unix)

[kvarnerexpress 0]

Hopefully I can explain my problem clearly. If not, please ask any questions to clarify.I'm looking at an issue where I'd need to make reference counted smart pointers multi-thread safe on a UNIX platform via mutexes. Object-embedded mutexes are not an option because of the memory footprint increase. Therefore, it was decided we use a static mutex that locks the entire class out from the reference count (i.e., only one smart pointer on the entire system at a time can do a reference count operation). BTW, these design decisions aren't mine to make.The issue I'm trying to wrap my head around right now has to do with the "boundaries" between executables and libraries, because these smart pointer objects are shared between a main executable and a bunch of modules (DLLs) in the current Windows implementation (which both include the same smart pointer header definition). I'm told that a static mutex in the smart pointer header would not work in this Windows environment, because each module would have a static mutex, when what I need is one global static mutex. (Side note: We get around this in windows using the InterlockedIncrement functions, but atomic assembly instructions are not available on the platforms we need to support).Since I'm not sure, my first question is if it is in fact true that in the Windows (.exe / .dll) situation, each module would in fact have it's own static member for that class. But the more important question is would this also be true on a UNIX platform where libraries are compiled separately and linked together? Would it make a difference between statically linked and dynamically linked libraries? Any insight is GREATLY appreciated, and feel free to ask questions if I'm not being clear. Thanks a bunch.