When I write C/C++ code for Windows platform, I usually use Windows APIs as necessary. But when it comes to multi-threading, I read the following quotaion from < Windows via C/C++ >
The CreateThread function is the
Windows function that creates a thread.
However, if you are writing C/C++
code, you should never call
CreateThread. Instead, you should use
the Microsoft C++ run-time library
function _beginthreadex. If you do not
use Microsoft's C++ compiler, your
compiler vendor will have its own
alternative to CrateThread. Whatever
this alternative is, you must use it.
AFAIK, a language run-time library for a certain platform is implemented with that platform's APIs. I think it is totally possible to call CreateThread() from my C/C++ code. And I quite did that. But I just don't understand why the above rule should be followed.
Many thanks for your insights.
Of course it's possible to use the Windows API's CreateThread directly.
But that leaves the runtime library uninformed about the new thread.
For the multi-threading support in the runtime library (and that includes functions that rely on static storage, e.g. I imagine it includes strtok) you need to keep the runtime library informed, and not only informed, but partially in charge so that e.g. failure to allocate whatever resources it needs for a thread, results in thread creation failure.
Cheers & hth.,
The c-runtime has numerous stateful variables that hold things, such as the current locale. These values have to be settable per thread otherwise code in oen thread (e.g. calling setlocale) could unduly influence code running in a different thread.
_beginthread wraps your thread in code that performs the necessary allocation AND deallocation of these per thread data structures.
If you call CreateThread directly, the structures will probably be allocated as required, but without the wrapper, the runtime will never know when the thread exits and they will leak.
Related
Thread-safe or thread-compatible code is good.
However there are cases in which one could implement things differently (more simply or more efficiently) if one knows that the program will not be using threads.
For example, I once heard that things like std::shared_ptr could use different implementations to optimize the non-threaded case (but I can't find a reference).
I think historically std::string in some implementation could use Copy-on-write in non-threaded code.
I am not in favor or against these techniques but I would like to know if that there is a way, (at least a nominal way) to determine at compile time if the code is being compiled with the intention of using threads.
The closest I could get is to realize that threaded code is usually (?) compiled with the -pthreads (not -lpthreads) compiler option.
(Not sure if it is a hard requirement or just recommended.)
In turn -pthreads defines some macros, like _REENTRANT or _THREAD_SAFE, at least in gcc and clang.
In some some answers in SO, I also read that they are obsolete.
Are these macros the right way to determine if the program is intended to be used with threads? (e.g. threads launched from that same program). Are there other mechanism to detect this at compile time? How confident would the detection method be?
EDIT: since the question can be applied to many contexts apparently, let me give a concrete case:
I am writing a header only library that uses another 3rd party library inside. I would like to know if I should initialize that library to be thread-safe (or at least give a certain level of thread support). If I assume the maximum level of thread support but the user of the library will not be using threads then there will be cost paid for nothing. Since the 3rd library is an implementation detail I though I could make a decision about the level of thread safety requested based on a guess.
EDIT2 (2021): By chance I found this historical (but influential) library Blitz++ which in the documentation says (emphasis mine)
8.1 Blitz++ and thread safety
To enable thread-safety in Blitz++, you need to do one of these
things:
Compile with gcc -pthread, or CC -mt under Solaris. (These options define_REENTRANT,which tells Blitz++ to generate thread-safe code).
Compile with -DBZ_THREADSAFE, or #define BZ_THREADSAFE before including any Blitz++ headers.
In threadsafe mode, Blitz++ array reference counts are safeguarded by
a mutex. By default, pthread mutexes are used. If you would prefer a
different mutex implementation, add the appropriate BZ_MUTEX macros to
<blitz/blitz.h> and send them toblitz-dev#oonumerics.org for
incorporation. Blitz++ does not do locking for every array element
access; this would result in terrible performance. It is the job of
the library user to ensure that appropriate synchronization is used.
So it seems that at some point _REENTRANT was used as a clue for the need of multi-threading code.
Maybe it is a very old reference to take seriously.
I support the other answer in that thread-safety decision ideally should not be done on whole program basis, rather they should be for specific areas.
Note that boost::shared_ptr has thread-unsafe version called boost::local_shared_ptr. boost::intrusive_ptr has safe and unsafe counter implementation.
Some libraries use "null mutex" pattern, that is a mutex, which does nothing on lock / unlock. See boost or Intel TBB null_mutex, or ATL CComFakeCriticalSection. This is specifically to substitute real mutex for threqad-safe code, and a fake one for thread-unsafe.
Even more, sometimes it may make sense to use the same objects in thread-safe and thread-unsafe way, depending on current phase of execution. There's also atomic_ref which serves the purpose of providing thread-safe access to underlying type, but still letting work with it in thread unsafe.
I know a good example of runtime switches between thread-safe and thread-unsafe. See HeapCreate with HEAP_NO_SERIALIZE, and HeapAlloc with HEAP_NO_SERIALIZE.
I know also a questionable example of the same. Delphi recommends calling its BeginThread wrapper instead of CreateThread API function. The wrapper sets a global variable telling that from now on Delphi Memory Manager should be thread-safe. Not sure if this behavior is still in place, but it was there for Delphi 7.
Fun fact: in Windows 10, there are virtually no single-threaded programs. Before the first statement in main is executed, static DLL dependencies are loaded. Current Windows version makes this DLL loading paralleled where possible by using thread pool. Once program is loaded, thread pool threads are waiting for other tasks that could be issued by using of Windows API calls or std::async. Sure if program by itself will not use threads and TLS, it will not notice, but technically it is multi-threaded from the OS perspective.
How confident would the detection method be?
Not really. Even if you can unambiguously detect if code is compiled to be used with multiple threads, not everything must be thread safe.
Making everything thread-safe by default, even though it is only ever used only by a single thread would defeat the purpose of your approach. You need more fine grainded control to turn on/off thread safety if you do not want to pay for what you do not use.
If you have class that has a thread-safe and a non-thread-safe version then you could use a template parameter
class <bool isThreadSafe> Foo;
and let the user decide on a case for case basis.
I recently implemented a utility to write user-mode dumps using MiniDumpWriteDump (part of the Debug Help Library). The implementation is separated into its own process. A target process can launch this utility and communicate with it to trigger writing a minidump.
This is all working as expected. I am not sure, though, how to interpret the rules with respect to concurrency for MiniDumpWriteDump:
All DbgHelp functions, such as this one, are single threaded. Therefore, calls from more than one thread to this function will likely result in unexpected behavior or memory corruption. To avoid this, you must synchronize all concurrent calls from more than one thread to this function.
Does the above refer to calls from different threads to a single process? Or do concurrent calls also require synchronization, if MiniDumpWriteDump is called in different processes (e.g. when each target process launches its own utility process)?
The problem is in the library: "All DbgHelp functions, such as this one, are single threaded".
Therefore, any process invoking this library will have to make sure that only one single thread is using the DbgHelp functions simultaneously.
Just use a lock before you use DbgHelp, that is, if your program using DbgHelp is multi-threaded (otherwise there's no problem).
Another way to remove this limitation is to add a (per-thread) context to the DbgHelp library: you move all (file-scope) static and (program-scope) global variables in a C structure passed as an argument to all library function calls.
I find myself in a situation in which I need to exit a cross-platform C++ application immediately, without running destructors, and also without causing a crash. How can I do that?
exit(0) runs the destructors;
quick_exit(0) is not implemented in VC++;
abort() causes a crash;
_Exit(0) does not seem implemented in VC++ (or at least does not appear in MSDN);
the documentation of _exit(0) is unclear as to whether it calls destructors – apparently, it calls them under Windows.
I believe that I can use quick_exit under non-Windows platforms, but I am lacking a solution for VC++.
Clarification (since people ask why I wish to avoid destructors) This is an optimization scenario. I am dealing with a large application that manipulates Gigabytes of RAM, allocated in complex graphs, with several processes, numerous threads, thread-safe reference-counting, watchdogs, etc. The memory management/resource deallocation mechanism is optimized for keeping the application responsive during runtime use and/or monitor possible errors (depending on build flags), but these mechanisms are clearly overkill during shutdown, keeping the CPU very busy for many seconds, draining the battery, etc – long after we are sure that all file descriptors/handles have been closed. This makes users unhappy, so I am experimenting how to improve this, preferably without having to refactor everything.
The call quick_exit was designed specifically for such scenarios, but isn't supported by VC++. So I'm looking for an alternative for that platform.
use C signals as defined in signal.h it should be supported on most platforms.
You specifically should be calling a raise() with a SIGABRT or kill().
I'm working on a C++ application which uses a library written in C by another team. The writers of the library like to call exit() when errors happen, which ends the program immediately without calling the destructors of objects on the stack in the C++ application. The application sets up some system resources which don't automatically get reclaimed by the operating system after the process ends (shared memory regions, interprocess mutexes, etc), so this is a problem.
I have complete source code for both the app and the library, but the library is very well-established and has no unit tests, so changing it would be a big deal. Is there a way to "hook" the calls to exit() so I can implement graceful shutdown for my app?
One possibility I'm considering is making one big class which is the application - meaning all cleanup would happen either in its destructor or in the destructor of one of its members - then allocating one of these big objects on the heap in main(), setting a global pointer to point to it, and using atexit() to register a handler which simply deletes the object via the global pointer. Is that likely to work?
Is there a known good way to approach this problem?
In the very worst case, you can always write your own implementation of exit and link it rather than the system's own implementation. You can handle the errors there, and optionally call _exit(2) yourself.
Since you have the library source, it's even easier - just add a -Dexit=myExit flag when building it, and then provide an implementation of myExit.
install exit handler with atexit and implement the desired behavior
If you want to make the C library more usable from C++, you could perhaps run it in a separate process. Then make sure (with an exit handler or otherwise) that when it exits, your main application process notices and throws an exception to unwind its own stack. Perhaps in some cases it could handle the error in a non-fatal way.
Of course, moving the library use into another process might not be easy or particularly efficient. You'll have some work to do to wrap the interface, and to copy inputs and outputs via the IPC mechanism of your choice.
As a workaround to use the library from your main process, though, I think the one you describe should work. The risk is that you can't identify and isolate everything that needs cleaning up, or that someone in future modifies your application (or another component you use) on the assumption that the stack will get unwound normally.
You could modify the library source to call a runtime- or compile-time-configurable function instead of calling exit(). Then compile the library with exception-handling and implement the function in C++ to throw an exception. The trouble with that is that the library itself probably leaks resources on error, so you'd have to use that exception only to unwind the stack (and maybe do some error reporting). Don't catch it and continue even if the error could be non-fatal as far as your app is concerned.
If the call exit and not assert or abort, there are a few points to get control again:
When calling exit, the destructors for objects with static lifetime (essentially: globals and objects declared with static) are still executed. This means you could set up a (few) global "resource manager" object(s) and release the resources in their destructor(s).
As you already found, you can register hooks with atexit. This is not limited to one. You can register more.
If all else fails, because you have the source of the library, you can play some macro tricks to effectively replace the calls to exit with a function of your own that could, for example, throw an exception.
I tend to use POSIX Threads, when programming in C, under Linux.
Without MFC
Question:
How would I then create threads in VC++?
Find more information on threads under win32?
Edit:
Brief illustrations
I LOVE stackoverflow - best resource for students!
Regards
if you're looking for a platform-independent method, use boost
there's also beginthread() and beginthreadex() functions. Both seem to be supplemental to Win32 API, in a sense that in many use cases, you still need to call some Win32 functions (such as CloseHandle for beginthreadex). So, if you don't care that much about platform compatibility, you might as well cut the foreplay and use CreateThread().
Win32 thread handling is documented here: http://msdn.microsoft.com/en-us/library/ms684852(VS.85).aspx
[edit1] example:
DWORD WINAPI MyThreadProc( void* pContext )
{
return 0;
}
HANDLE h = CreateThread( NULL, 0, MyThreadProc, this, 0L, NULL );
WaitForSingleObject(h, TIME); // wait for thread to exit, TIME is a DWORD in milliseconds
[edit2] CRT & CreateThread():
per MSDN:
A thread in an executable that calls the C run-time library (CRT) should use the _beginthreadex and _endthreadex functions for thread management rather than CreateThread and ExitThread; this requires the use of the multi-threaded version of the CRT. If a thread created using CreateThread calls the CRT, the CRT may terminate the process in low-memory conditions.
You should not use the raw Win32 CreateThread() API.
Use the C runtime's _beginthreadex() so the runtime has an opportunity to set up its own thread support.
You can use either the CRT function _beginthreadex() or the Windows API function CreateThread(). _beginthreadex() is required for early versions of VC++ that had a CRT that didn't lazily initialize thread-local storage. CreateThread() is fine in at least VS2005 and up.
You probably want to take a look at the CreateThread() function.
Use _beginthread() or _beginthreadex() to create a new thread. Do NOT use the Win32 function CreateThread() -- it does not properly initialize the multithreaded aspects of the C runtime. See also this question.
Some good books on the subject are Petzold's Programming Windows and Richter's Programming Applications for Windows. In particular, the latter goes into server side programming such as thread and synchronisation API's in a lot of depth.
EDIT: For code snippets, Google is your friend. For example This article has some minimal thread examples.
There is also the _beginthread() function you can look up. It differs a bit from CreateThread(), you should be aware of the differences before choosing one.