Is it safe to call std::thread::join function under win32 DLL_PROCESS_DETACH?

Question

0.00/5 (No votes)

See more:

Please look at code snippet below // these code blocks defined under single .cpp unit in DLL project
------------------ DLL -------------------------

C++

static std::thread sendMessageThread; // define as local static to cpp
//....//
bool  callFunction()
{
   /// Some simple code without spawning any thread or fibers
 }
void WINAPI OnEngineStart()
{
    sendMessageThread = std::thread(callFunction);
};

    BOOL WINAPI DllMain(HINSTANCE hDll, DWORD fdwReason, LPVOID lpvReserved)
    {
        switch (fdwReason)
        {
        case DLL_PROCESS_ATTACH:
            break;
        case DLL_PROCESS_DETACH:
            if (sendMessageThread.joinable())
            {
                sendMessageThread.join(); // is this safe?
            }
            break;
        case DLL_THREAD_ATTACH:
            break;
        case DLL_THREAD_DETACH:
            break;
        }

    return TRUE;
};

------------------------------------- DLL --------------------------

If the process which loaded the DLL call OnEngineStart function then whenever it unloads the DLL(using FreeLibrary WinAPI function), will it wait until sendMessageThread gets finished? and continue with DLL unload procedure?

What I have tried:

I run the program with this DLL,program never crash and halt.But I found these stuff:
Does creating a thread from DllMain deadlock or doesn’t it? – The Old New Thing[^]
Dynamic-Link Library Best Practices (Windows)[^]

Posted 26-Sep-17 5:11am

Buddhi Chaturanga

Updated 29-Sep-17 2:06am

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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

**`Randor`** · Answer 1 · 2017-09-29T02:06:00

No, you are doing exactly what Raymond Chen describes in his blog entry. You are waiting for the thread in your DLL_PROCESS_DETACH. Make sure that you understand what 'DLL notifications are serialized' means.

I think I know a way to demonstrate why this is a bad idea... add some code in your sendMessageThread that calls getenv_s, _wgetenv_s[^]. Also add some code to your parent process to load/unload the DLL periodically. This should eventually cause your code to deadlock. The reason for the deadlock is that the CRT accesses a global _ENV_LOCK and will potentially cause a race condition. There are dozens of other scenarios that will cause a deadlock.

One possible solution is to change your architecture by adding a OnEngineStop thread message and do your waiting there.

Best Wishes,
-David Delaune