what is the best way to initialize my global data in shared library?

Question

I have a single class which does all the required initialization. currently i have declared a global object of this class type, which is being instantiated on library load. I've seen other ways, like delaring

BOOL APIENTRY DllMain

entry point for the shared library, and does the actual initialization on process attach.

does this differ from letting the implicit global initialization to its job? which way is better?

FYI DllMain *can* be called more than once. There are multiple events that trigger this function. Despite its name it's not a true "main". — Chris Eberle, Aug 12 '11 at 04:16
please add comments and some code to make me understand what u want. — amod, Aug 12 '11 at 04:36

score 6 · Accepted Answer · answered Aug 12 '11 at 05:44

This is what happens during C++ DLL startup:

System calls DLL's entry point, generated by you compiler
Entry point calls DllMainCRTStartup (name may differ), which initializes C/C++ runtimes and instantiates all global objects.
DllMainCRTStartup then calls user-defined DllMain.

I personally prefer DllMain, because this way I can explicitly control order of initialization. When you use global objects in different compilation units, they will be initialized in random order which may bring some unexpected surprises 10 minutes before the deadline.

DllMain also let's you do per-thread initialization, which you can not achieve with global objects. However, it is not portable to other platforms.

P.S. You do NOT need mutex in DllMain, as all calls to it are already serialized under process-global critical section. I.e. it is guaranteed two threads will not enter it at the same time for any purpose. This is also the reason why you should not communicate with other threads, load other libraries etc. from this function; see MSDN article for explanation.

what happens if two processes are trying to load the library? each will have its own data segment, right? so the global object will be unique for each process, right? — sramij, Aug 12 '11 at 05:54
It's also worth noting that the critical section is acquired before p.1, not before p.3, so you should not call LoadLibrary from you global object's constructors/destructors either. — hamstergene, Aug 12 '11 at 06:14

score 2 · Answer 2 · edited Aug 19 '14 at 17:24

A couple of things that should never be done from DllMain:

Call LoadLibrary or LoadLibraryEx (either directly or indirectly). This can cause a deadlock or a crash.
Synchronize with other threads. This can cause a deadlock.
Acquire a synchronization object that is owned by code that is waiting to acquire the loader lock. This can cause a deadlock.
Initialize COM threads by using CoInitializeEx. Under certain conditions, this function can call LoadLibraryEx.
Call the registry functions. These functions are implemented in Advapi32.dll. If Advapi32.dll is not initialized before your DLL, the DLL can access uninitialized memory and cause the process to crash.
Call CreateProces. Creating a process can load another DLL.
Call ExitThread. Exiting a thread during DLL detach can cause the loader lock to be acquired again, causing a deadlock or a crash.
Call CreateThread. Creating a thread can work if you do not synchronize with other threads, but it is risky.
Create a named pipe or other named object (Windows 2000 only). In Windows 2000, named objects are provided by the Terminal Services DLL. If this DLL is not initialized, call to the DLL can cause the process to crash.
Use the memory management function from the dynamic C Run-Time (CRT). If the CRT DLL is not initialized, calls to these functions can cause the process to crash.
Call functions in User32.dll or Gdi32.dll. Some functions load another DLL, which may not be initialized.
Use managed code.

Probably useful but poorly formatted, care to change the code block to a quote or a list? — Cape Code, Aug 19 '14 at 17:23

score 1 · Answer 3 · answered Aug 12 '11 at 04:36

You need a static boolean initialization variable and a mutex. Statically initialize "initialized" to 0. In your DllMain(), make a call to CreateMutex(). Use bInitialOwner=0 and a unique name for lpName that's unique to your application. Then use WaitForSingleObject() to wait for the mutex. Check if initialized is non-zero. If not, do your initialization, and then set initialized to 1. If initialized is non-zero, do nothing. Finally, release the mutex using ReleaseMutex() and close it using CloseHandle().

Here's some pseudo-code, with error and exception handling omitted:

initialized = 0;

DllMain()
{
    mutex = CreateMutex(..., 0, "some-unique-name");
    result = WaitForSingleObject(handle, ...);
    if (result == WAIT_OBJECT_0) {
        if (!initialized) {
            // initialization goes here
            initialized = 1;
        }
    }
    ReleaseMutex(mutex);
    CloseHandle(mutex);
}

I thought that the initialization was single-threaded, why is the mutex necessary then ? — Matthieu M., Aug 12 '11 at 06:46
afaik, Windows Mutexes are global for processes, CriticalSection is working for Threads in a single process. — qdbp, Dec 11 '17 at 16:04

score 0 · Answer 4 · answered Aug 12 '11 at 04:35

hi i would recommend u to prefer a signleton class where u can only create a single object of a class and use it. Sigleton class can be created with a private constructor. Now suppose ur class A is a singleton class its object can be used in a constructor of each Class which u want to initialize. Please give us some sample code so other may help u better.

what is the best way to initialize my global data in shared library?

4 Answers4