Open philave opened 7 years ago
The scope of this project initially was to provide just the basic platform-dependent primitives, on top of which the rest of the missing functionality could be implemented. Contribution of implementation of the remaining missing functionality is certainly welcome.
We've used an ugly hack to enable the use of the stock std::future. Check: https://github.com/spring/spring/blob/develop/rts/System/Platform/Win/Future.h and https://github.com/spring/spring/blob/develop/rts/System/Platform/Win/Future.cpp
I think you will be interested in https://gcc-mcf.lhmouse.com/. :joy:
Rather than reinvent std::thread
, std::mutex
, std::condition_variable
etc once more, I decided to implement __gthread_*
functions directly which GCC's threading stuff is based on, which eventually enables everything including std::once_flag
, std::promise
, std::shared_mutex
, std::notify_all_at_thread_exit()
, etc.
Introduction: https://github.com/lhmouse/mcfgthread/wiki Benchmarking: https://github.com/lhmouse/mcfgthread/wiki/Benchmarking
@lhmouse I'm all for fixing this stuff at the gthread
level and then just letting libstdc++ do its own thing, but I'd rather avoid:
In facts, I was thinking of completing the gthr-win32 stuff with what is missing (essentially, thread creation/join/detach and condition variables). It would be nice to finally have the choice between mcfgthread (bleeding edge, for new systems) and a complete classic win32 thread model (slower, but with a simpler and more compatible implementation).
I'm particularly obsessed by the idea of having a "simple", reliable gthread layer, as the "posix" (=winpthread) threading model aimed to something similar, but unfortunately is complex, messy code, is subtly broken (we found race conditions in thread creation/join/detach, with threads ending up having their associated support structure completely mixed up), with no clear way to salvage it. The fact that the bug linked above went completely ignored is also a strong indicator that winpthreads is essentially abandoned.
@cvtsi2sd
@lhmouse I'm all for fixing this stuff at the gthread level and then just letting libstdc++ do its own thing, but I'd rather avoid:
- breaking compatibility with older Windows versions
- exploiting undocumented interfaces
Well then you might have few other options. You have to either implement condition variables yourself (it is hard to implement correctly, we know) or use the native one since Vista.
In facts, I was thinking of completing the gthr-win32 stuff with what is missing (essentially, thread creation/join/detach and condition variables).
You can do that. GCC's gthr.h has documented what is needed well.
It would be nice to finally have the choice between mcfgthread (bleeding edge, for new systems) and a complete classic win32 thread model (slower, but with a simpler and more compatible implementation).
Thank you.
I'm particularly obsessed by the idea of having a "simple", reliable gthread layer, as the "posix" (=winpthread) threading model aimed to something similar, but unfortunately is complex, messy code, is subtly broken (we found race conditions in thread creation/join/detach, with threads ending up having their associated support structure completely mixed up), with no clear way to salvage it. The fact that the bug linked above went completely ignored is also a strong indicator that winpthreads is essentially abandoned.
I can't agree with you more. There are more issues with winpthreads. The fact that the bug is ignored might be due to the requirement of specialized knowledge. People can't fix it without enough knowledge, which is not practical either because those people have been busy with their work, life, etc.
Hence the goal of mcfgthread is to be as tiny as possible. There is little unnecessary code. A few important implementation details are documented on its Wiki pages.
With shared_mutex
implemented, it's time to take a fresh look at which features are still missing:
notify_all_at_thread_exit
.
mutex
to the waiting thread would require unlocking it in the original thread and re-locking it in the waiting thread.notify_all_at_thread_exit
, the functions std::promise::make_ready_at_thread_exit
and std::promise::set_value_at_thread_exit
can use a waiter-thread without transferring ownership of a mutex
between threads, depending on how the classes are implemented.
Currently, std::future class doesn’t work as all of its implementation is hidden under'
_GLIBCXX_HAS_GTHREADS
macro. g++ generates error: invalid use of incomplete type 'class std::future