在调用exit之后访问其他线程中的全局变量是否安全？

Question

I am analysing a dump one of the stack shows exit has been called

#0  0x00007fe2beac80a4 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x00007fe2beac3444 in _L_lock_1087 () from /lib64/libpthread.so.0
#2  0x00007fe2beac32b6 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x00007fe2bece5325 in _dl_fini () from /lib64/ld-linux-x86-64.so.2
#4  0x00007fe2bd73a5e5 in __run_exit_handlers () from /lib64/libc.so.6
#5  0x00007fe2bd73a635 in exit () from /lib64/libc.so.6

At the same time dump is in another thread when is trying to access global variable. So is it safe to access global variable in another thread after exit has been called? Would the global variable be destroyed "any time" after exit called?

Answer 1

So is it safe to access global variable in another thread after exit has been called?

On any non-trivial OS, yes. It's even safe to access local/automatic storage vars in other threads after exit has been called. Windows/linux etc. designers did think of this issue at design-time and so developed their process-termination sequence so that ALL threads in a process are stopped before any memory is released. Process threads that are not in the running state have their state changed so that they can never be run again. Process threads running on a different core than the thread that called 'exit' have their execution forcibly removed by means of a hardware interrupt to the core/s running them. Only when ALL threads are stopped are resources like memory deallocated and released for re-use by other processes.

Would the global variable be destroyed "any time" after exit called?

Yes. The memory-segment hosting the global will be released by the OS at some time after exit is called. This does not matter, however, since none of the process threads will be running at that time, whenever it is.

Note that all exit() calls are created equal:) Some will run static dtors etc. before calling the OS to terminate the process and this can indeed cause problems with threads that call them that may be still running, resulting in possible UB/segfaults. This becomes more likely with non-POD classes with non-trivial dtors.

If this is found to be an actual issue, either use an exit call that does not run the static dtors, (this may, or may not, matter, depending on what the dtor does, or needs to do), or avoid the issue by not using static globals, (not a bad plan anyway), or, as a last resort, go through the miserable, and usually avoidable, exercise of trying to cooperatively terminate the offending threads in user space before calling exit() .