pthread_yield() vs std::this_thread::yield()
Monty and I had an argument recently regarding pthread_yield() and std::this_thread::yield() usage. I do want to make this discussion public, so that we can pick either approach, get it documented and make sure everybody is aware of reasoning and decision. Probably even add a bb check that wouldn't allow unwanted function calls to pass. Lets try to keep this discussion focused on std::this_thread::yield() and avoid discussing other C++11 features. Since I'm biased towards std::this_thread::yield() I'd let Monty elaborate his concerns and explain why he prefers pthread_yield(). But generally it comes to compatibility and portability. My position is: pthread_yield() should be removed in favour of std::this_thread::yield(). Benefits: 1. Must be available to all current MariaDB versions. C++11 is a must since 2018. 2. Compatibility and portability, which we don't have to care about. 3. I have no performance concerns after analysing how it is implemented by clang and gcc. 4. Goes inline with "MDEV-35461 - Remove redundant checks for standard library functions" 5. Standard things looks more community-friendly, e.g. why should MSVC developers care about POSIX threads? Currently pthread_yield() can be defined to: 1. SwitchToThread() - Win32 (Wlad, 2009) MSVC seems to support std::this_thread::yield() since 2015: https://learn.microsoft.com/en-us/cpp/standard-library/thread-functions?view... 2. thr_yield() - Solaris (Serg, 2009) Oracle Developer Studio 12.6 supports std::this_thread::yield() since 2017: https://docs.oracle.com/cd/E77782_01/html/E77789/bkabe.html#OSSCPgnyio 3. pthread_yield_np() - OS X (Serg, 2009) XCode is based on clang, which supports std::this_thread::yield() since 2013. sched_yield() - default (Serg, 2009) pthread_yield() - deprecated since 2021 (Serg, 2009) Possible concerns: 1. Compatibility with recent platforms. C++11 is widely available, thread models seem to be well supported. InnoDB uses std::this_thread_yield() since 2021. 2. Compatibility with older (ancient?) platforms. We're way off into C++11 since 2018. Making recent MariaDB compile on such platforms is probably going to be a heavy effort. If we do really want to have these platforms supported, they must be present in buildbot. 3. Performance impact of std::this_thread::yield(). See below. In many cases it is just a wrapper around functions like sched_yield. clang: libcxx/include/__thread/this_thread.h:inline _LIBCPP_HIDE_FROM_ABI void yield() _NOEXCEPT { __libcpp_thread_yield(); } libcxx/src/support/win32/thread_win32.cpp:void __libcpp_thread_yield() { SwitchToThread(); } libcxx/include/__thread/support/pthread.h:inline _LIBCPP_HIDE_FROM_ABI void __libcpp_thread_yield() { sched_yield(); } gcc additionally supports VxWorks: yield() noexcept { #if defined _GLIBCXX_HAS_GTHREADS && defined _GLIBCXX_USE_SCHED_YIELD __gthread_yield(); #endif } int __gthread_yield (void) { return taskDelay (0); } __GTHREAD_INLINE int __gthread_yield (void) { return __gthrw_(sched_yield) (); } Regards, Sergey
On Fri, 9 May 2025 at 07:54, Sergey Vojtovich via developers < developers@lists.mariadb.org> wrote:
Monty and I had an argument recently regarding pthread_yield() and std::this_thread::yield() usage.
My position is: pthread_yield() should be removed in favour of std::this_thread::yield(). Benefits:
Agree here.
1. Must be available to all current MariaDB versions. C++11 is a must since 2018.
per https://jira.mariadb.org/browse/MDEV-35837 we've declared our current standard on 11.8+ as C++17
2. Compatibility and portability, which we don't have to care about.
I do pity our FreeBSD/OpenBSD/Illumios/MacOS maintainers that frequently submit one or two changes every second release.
3. I have no performance concerns after analysing how it is implemented by clang and gcc. 4. Goes inline with "MDEV-35461 - Remove redundant checks for standard library functions" 5. Standard things looks more community-friendly, e.g. why should MSVC developers care about POSIX threads?
To attract new developers, both employment and contributions, we should use all stable features that exist in the compilers supported by the supported distros of our codebase. It seems the mariadb.com job adverts on Senior C++ Database Engine Developer have qualification "You use the C++20 standard since 2020 and C++17 since 2017.". How disappointed are they going to be in employment when C++20 is a no go and even C++17 construct usage is rare? Do you think staff will be retained up until when C++20 becomes allowed is to be possible? Insisting on code constructs that existed before many new developers are born is a sure way to put them off. Thinking back to my early career (also a a long time ago) I had no desire to work on COBOL or Fortran (even though I didn't and still don't know anything about them). To avoid a "I worked on those", this isn't a reflection of the technology, just I didn't, and still aren't, in tech to work on "old stuff". The Foundation goal of continuity and openness can only be met while people are willing and able to work in the codebase. 6. complexity Currently highlighted below, the variety of options is creating large complexity in the codebase. We should trust, but validate via testing that C++ implementers can implement these appropriately. They have great skills, and are typically employed by a distro or hardware platform company that has easy access to those hardware professionals to validate an exceptionally optimal implementation. As a highlight of an old PR of mine where we took a "we know better stance" and never re-revaluted in 18 years https://github.com/MariaDB/server/pull/698 (which got effect, but we retained the old code under a not accessible define, but still got effort better spent elsewhere put into it recently maintain to conform to compatible behaviour). As our current bug queue indicates that we've got enough to handle on the database layer of things without maintaining, dare I exaggerate slightly not-invented-here, low level constructs well maintained elsewhere.
Currently pthread_yield() can be defined to:
1. SwitchToThread() - Win32 (Wlad, 2009)
...
Hi, Daniel, On May 09, Daniel Black via developers wrote:
It seems the mariadb.com job adverts on Senior C++ Database Engine Developer have qualification "You use the C++20 standard since 2020 and C++17 since 2017.".
This is a ColumnStore position, ColumnStore is much more bleeding edge. Regards, Sergei Chief Architect, MariaDB Server and security@mariadb.org
participants (3)
-
Daniel Black -
Sergei Golubchik -
Sergey Vojtovich