Jochen Kalmbach's WebLog

Why you should never call Suspend/TerminateThread (Part II)

In the last part I only showed an simple example for a deadlock if you call SuspendThread in the wrong moment.

Today I want to list all function in the CRT (VC7.1) which are affected by thread-synchronization. If you use such a function after you suspended a thread (which also uses this function (or functions which uses the same critical section) at the time you suspended it) you will sometimes produce an deadlock.

In the C-Runtime the usage of thread synchronizing via Enter/LeaveCriticalSection is very high (in the multithreaded version; be aware tht the VC8 only supports the multithreaded version of the CRT!). A list of some locks is in mlock.c. In the following I will list the functions which are affected by the given lock-entry.

_SIGNAL_LOCK: raise and internally in "ctrlevent_capture" which is registered via SetConsoleCtrlHandler

_IOB_SCAN_LOCK: _fcloseall, _flushall, fflush, _rmtmp, _setmaxstdio, and via _getstream: _tfdopen, tmpfile

_TMPNAM_LOCK: _ttempnam, tmpfile

_CONIO_LOCK: _cgets, _cgetws, _cputs, _cputws, _getch, _getche, _getwch, _getwche, _kbhit, _ungetch, _ungetwch, _putch, _putwch

_HEAP_LOCK: operator new, operator delete, malloc, realloc, free, calloc, _expand_dbg, _free_dbg, _realloc_dbg, _msize_dbg, _CrtCheckMemory, _CrtSetDbgFlag, _CrtDoForAllClientObjects, _CrtIsMemoryBlock, _CrtMemCheckpoint, _CrtMemDumpAllObjectsSince, _set_new_handler, _heapadd, , _heapchk, _heapmin, _heapwalk, and all other functions which are allocating memory (so you can assume all functions as affected)

_UNDNAME_LOCK: TODO

_TIME_LOCK: TODO

_ENV_LOCK: TODO

_EXIT_LOCK1: TODO

_POPEN_LOCK: TODO

_LOCKTAB_LOCK: TODO

_OSFHND_LOCK: TODO

_SETLOCALE_LOCK: TODO

_MB_CP_LOCK: TODO

_TYPEINFO_LOCK: TODO

_DEBUG_LOCK: TODO

_STREAM_LOCKS: TODO

---