Windows clients occasionally fail to terminate cleanly after exit() or return from main(). I have examined a large number of stack traces, mostly gibberish presumably from rogue memory writes some time in the past. Two refreshingly clear traces showed failure when direct or indirect threading calls were made from inside a static destructor: ~IOThread and ~WinSockSetup.
If a DLL (shared object) is winding up due to the library being unloaded (FreeLibrary), the DLL code has an obligation to clean up resources that could leak, and since the process hasn't exited, existing threads live on and threading primitives are trustworthy. In this case the Windows library may (and should) follow the Linux clean up logic in its static destructors.
If the DLL is winding up due to exit() (or return from main()), it is undefined how quickly other threads will be forcefully terminated. Locks may be held indefinitely or falsely released (changed in the Vista time frame). In this case, any fancy footwork is dangerous. The best course of action is to let the OS clean up things it would anyway, i.e. do nothing if possible.