Singleton class in a static library

Question

Suppose I have a singleton class S in a static library, this could be linked with the other dynamic libraries D1 D2 D3,

So from what I understand the class S will have a separate instance in each D1, D2 and D3 and this would be true even if it is not a singleton (like global)

Is there any way to prevent multiple copies of class S? I cannot put the singleton S in another Dynamic library.

                 Executable
                /   |   \   \
              D1    D2  D3  D4 
               |    |   |
               S    S   S

EDIT: The singleton S is in a separate static library that links with D1 D2 D3... separately.
The singleton is allocated in the heap, only the pointer is static

static s::instance()
{
    static smart_ptr<S> ptr = NULL;
    if(ptr == NULL) ptr = new S;
    return ptr;
}

Edit2:

I made a simple test case to check things out This is a sample makefile (replace .dll by .so) i made to check things out, I checked it on Ubuntu and Cygwin, both g++ compilers and the behaviour was different. cygwin created 2 different objects but but ubuntu created 1 objects

all: dynamic1 dynamic2 main

static: static.cpp 
    g++ -c -fPIC static.cpp -o obj/static.o
    ar rvs lib/static.a obj/static.o 

dynamic1: static dynamic1.cpp
    g++ -fPIC -shared dynamic1.cpp lib/static.a -o lib/libdynamic1.dll

dynamic2: static dynamic2.cpp
    g++ -fPIC -shared dynamic2.cpp lib/static.a -o lib/libdynamic2.dll

main: dynamic1 dynamic2 main.cpp
    g++ --std=c++11 main.cpp -ldynamic1 -ldynamic2 -o lib/main -L./lib

what is your intention? If you want to control access to shared resources you could use interprocess synchronization, for example using [boost](http://www.boost.org/doc/libs/1_61_0/doc/html/interprocess/synchronization_mechanisms.html) — Jonathan Cichon, Jun 10 '16 at 07:50
you should add a std::call_once to your instance assignment, at least if you have multible threads accessing the instance — Jonathan Cichon, Jun 10 '16 at 13:36

score 21 · Accepted Answer · edited Oct 25 '16 at 12:59

If your dynamic linker is not broken, you should not have any problems. Even if every dynamic library actually contains the object files from the static library S, the dynamic loader should be clever enough to determine that they correspond to the same symbol, and use consistently the same addresses throughout the whole application.

In short, if your system ~~is not broken~~ has a true dynamic loader, there is no problem here

Per your edit, I confirm that above is the way it should be in a nice world and the way it is in Unix-like systems. You say it works on Ubuntu, and I can confirm is works the same on FreeBSD.

But on Windows, it is unfortunately different. You do not have a true dynamic loader like ld.so but you only require addresses of exported functions or data from the DLL. As a result, each DLL will use its own copy of the singleton, because each will contain its own copy of the code and use it because there is no global linking phase to merge that.

What is even worse is that I cannot imagine any simple workaround: static linking and dynamic linking have different behaviour full stop. That means that as soon as you use dynamic linking on Windows, a singleton or any shared data that can be accessed from at least two different DLLs must reside in a single place, meaning a DLL.

TL/DR: If your system has a real dynamic loader (Unix like have), you do not have to bother about static or dynamic linking, the loader (ld.so) will care about it. On Windows, that has no dynamic loader but a run-time LoadLibrary API call, any shared data must reside in one and only one module.

score 3 · Answer 2 · edited May 23 '17 at 12:26

3

there are two case of implementation for the singletone.

1, single instance as a pointer, getInstance will dynamically allocate memory from heap in this case.

2, single instance as a static member and there is no memory allocation happens.

The following link discusses where is the static memory located: Where are static variables stored (in C/C++)?

In any of above implementation: If D1, D2, D3 and D4 are in same application and thus same process (e.g. used in different threads), then they share same singleton. If D1, D2, D3 and D4 are belong to different process, i.e. they have its own memory space and thus don't share same singleton.

edited May 23 '17 at 12:26

Community

1
1

answered Jun 10 '16 at 06:36

Kevin SUN

158
1
7

i removed it as answer as I found that the behaviour is different – tejas Jun 10 '16 at 12:18
1

I found this answer to be wrong under MSVC. Using boost_serialization as static library happens to instantiate its backend singletons (eg. for type info) once per module linking the static library. This in turn breaks the whole purpose of this backend (unregistered class exception raised) – S. Paris May 20 '17 at 14:17

Singleton class in a static library

2 Answers2

Linked