Re: Adding a new thread model to GCC

[Jacek Caban <jacek@codeweavers.com>]

On 10/24/22 05:40, LIU Hao via Gcc-patches wrote:
> 在 2022/10/21 20:34, i.nixman@autistici.org 写道:
>>
>> got it...
>> anyway it seems logical to me the way I proposed :)
>>
>>
>
> Below is a message forwarded from mingw-w64-public, elaborating the 
> necessity of a new thread model.
>
> As there are objections from other mingw-w64 developers, I am putting 
> those patches against mingw-w64-crt on hold for now. Despite that, all 
> threading facilities - mutexes, condition variables, once flags, etc. 
> - are still fully functional within the mcf thread model.
>
> In addition, I will keep maintaining my personal builds (from GCC 12 
> release branch) with these patches at https://gcc-mcf.lhmouse.com/.
>
>
> -------- Forwarded Message --------
> 在 2022/10/23 18:06, Jacek Caban 写道:
> >
> > Please, let's not do that. It's possible to fix existing 
> implementations, we don't need to make
> > things more complicated than they are.
> >
>
> Okay okay, I think I have to compose a thorough list of problems that 
> we are facing at the moment, and had better have a permalink to the 
> mailing list archive that I can reference elsewhere. I have been tired 
> of repeating the same grounds of arguments again and again:
>
>
> 1. In a DLL, destructors of static objects and callbacks that are 
> registered
>     with `atexit()`, are executed by `LdrShutdownProcess()`, after all 
> the other
>     thread have been terminated `ZwTerminateProcessO(NULL, status)`. 
> This means
>     that, if another thread has been terminated while holding a mutex, 
> the mutex
>     can never get unlocked. If a destructor attempts to lock the same 
> mutex,
>     deadlocks will occur. Destructors of executables do not suffer 
> from this
>     issue, because they are executed before `RtlExitUserProcess()`.
>
>     Standard behavior: Static destructors and exit callbacks should be 
> executed
>     while other threads are running. If another thread attempts to 
> access a
>     destroyed object, the behavior is undefined; the user is 
> responsible to
>     prevent this from happening, by joining or suspending it.
>
>
> 2. Following 1, in a DLL, static destructors and exit callbacks are still
>     invoked when `_Exit()` or `quick_exit()` is called.
>
>     Standard behavior: `_Exit()` should not perform any cleanup; not 
> even open
>     files are flushed. `quick_exit()` shall invoke all quick-exit 
> callbacks in
>     reverse order, then call `_Exit()`.
>
>
> 3. There is a use-after-free bug [1] about thread-local destructors. I 
> suspect
>     this is caused by emutls, because GCC uses `__cxa_thread_atexit()` to
>     register thread-local destructors, which could interleave with
>     `emutls_destroy()`.
>
>     Standard behavior: This is not allowed to happen. mcfgthread 
> solves this
>     issue by running thread-local destructors and thread-specific key
>     destructors as two separate passes [3].
>
>     [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80816
>     [2] 
> https://github.com/gcc-mirror/gcc/blob/f84e4fb44aa26b71fbc64e0532fd24d96e5caa3f/libgcc/emutls.c#L96
>     [3] 
> https://github.com/lhmouse/mcfgthread/blob/63e034d375caf585e2921cd3455f1048feb2172d/src/xglobals.c#L249
>
>
> 4. In the win32 thread model, thread-specific key destructors are 
> called at
>     process exit [4], after static destructors.
>
>     Standard behavior: They shall be called only when a thread exits, 
> and the
>     associated thread-specific values are not a null pointer. They 
> shall not be
>     called when a program terminates; instead, users are responsible for
>     deallocating such resources before calling `exit()`. This 
> requirement is
>     missing in POSIX, but formally specified by ISO/IEC 9899:2017, as 
> the 4th
>     paragraph in '7.26.6.1 The tss_create function'.
>
>     [4] 
> https://github.com/mingw-w64/mingw-w64/blob/d0a034a04d312434b842c4869a8a900568d8db98/mingw-w64-crt/crt/tlsthrd.c#L134


Those 4 points describes problems that you solve in the new threading 
model, but there is no reason they can't be fixed for existing threading 
models. In fact, ideally they would be fixed for all threading models. 
Except now we need to worry about one more threading model, meaning that 
future bugs will be even harder to fix.


>
> 5. Wait operations, of timed mutexes and condition variables, should take
>     absolute time points as `struct timespec`.
>
>     Standard behavior: Both POSIX and ISO C specifies them as such, 
> while all
>     Windows APIs take relative durations as a 32-bit integer of 
> milliseconds,
>     which can also easily get overflown.


This also may be supported in existing threading models. Overflow is 
trivial to fix by waiting in a loop. (There are other reasons why OS 
support for absolute timeout is slightly better, but the price of this 
design decision makes it questionable. I plan to elaborate more on that 
on mingw ML, but I need to find time to do a bit of research first).


Jacek