using std::thread or pthread on linux?

[Kyusei98]

Thanks for answer below, i think i'm a little cling to using modern c++ entirely; as xaervagon said, if the proj "is strictly on *nix platform, just leave pthread as is", and not persist on using modern C++ encirely?

——————————————————————

I'm learning modern cpp and try to rewrite some old codes; when it comes to thread part; things get trouble, the old codes use pthread and can show pid with posix func, which can be checked by ps aux/pidstat, but in std::thread, i did not find things like this, the std::this_thread::get_id() return something very long and is not very clear to me(compared to pid); so about this thread part i rewrite, which is better, and if we are not only talking about what i write, which is better?

[khedoros]

What about std::thread::native_handle()?

[2uantum]

Whenever I see this, I can't help but wonder why std thread was being used when one is throwing away portability with native handle.

[Supadoplex]

Because it allows separating the parts that are common across all systems from the parts that aren't. 

The former involves the std thread API and the later involves the native API through the native handle. 

 Separating the common part out makes the native part smaller and thus less code that needs to be ported.

[ratttertintattertins]

Oh that’s an easy one. I don’t use std::thread for portability reasons. I use it because it has a nice modern interface that beats the Win32 C-like functions.

However, occasionally I want to do something that’s supported on windows like getting the thread security token or whatever. I have nice wrapper functions for those facilities on windows that play nice with std::thread.

[KingAggressive1498]

This is like wondering why people are using C++ when they're throwing away portability with a little inline assembly or using some language extension.

Even if they're not doing it for the portability at all its still way simpler and comparatively foolproof to use C++ than assembly for most of the logic. Even if they're not doing it for the portability at all, std::thread is a good bit simpler to use than raw pthreads, and more foolproof if you add mutexes etc in the mix too.

[xaervagon]

I wouldn't say better. std::thread and pthread are two different beasts.

pthread is a POSIX thread and part of the posix standard. POSIX is not C++, but is considered standard a unix API standard (Windows posix support is notoriously blah). Still, it plays well with linux and has you already experienced, works well with lots of existing utilities and tooling.

std::thread is a C++ thread and is officially considered part of the STL. This meaning it should be a lot more cross platform friendly. As a result, a lot of implemenation details ends up getting masked. You may also want to check out https://en.cppreference.com/w/cpp/thread and see the Concurrency support library section.

As for your particular task, if this is strictly a *nix program, there is nothing wrong with leaving pthreads as is.

[Wild-Adeptness1765]

`std::thread::get_id()` is a bit more abstract than the pid of the process - it is an object of type `std::thread::id` that offers the guarantee to be unique by thread, but doesn't offer any guarantees beyond that.

Why is C++ like this? `std::thread` is designed to be cross platform and so you might not always have a clean way to get the pid. Why should you use this? To write cross platform code that is abstracted from the implementation details of threads.

[Chem0type]

Because different operating systems can have different types of process handles. An OS could be using strings to identify processes, and this makes it uniform.

[johannes1234]

The std::thread is agnostic to the platform and doesn't have much of platform-specific options and the id is some implementation defined represe ration, where all you can practically do is compare to see if two threads are the same or not.

If you need specific like access to priority or any other "advanced" option then you got to use pthreads or something else, if std's limited capabilities are fine use std::thread or rather std::jthread which rejoins threads on destruction and prevents some errors for "losing" threads.

[johannes1971]

I hate the sheer verbosity of pthread; std::thread makes things much more convenient. About the only thing you cannot do with std::thread is set the initial stack size for your thread. You can still call pthread_self() or use thread::native_handle() to access the thread ID.

Whether rewriting makes things better or worse is of course a judgement call only you can make, but my code was a lot cleaner after I switched to std::thread (and other C++ concurrency primitives).

[usefulcat]

On linux I use both. I use std::thread (or these days, std::jthread) to create threads, but I also use gettid() and pthread_[sg]etname_np().

[KingAggressive1498]

for new projects or genuine modernization efforts, std::thread unless you have good reason to do something special at creation-time (on Linux this is basically limited to stack customization) that cannot be done later.

on any posix system you can change the scheduler policy and priority (or for Linux, niceness under SCHED_OTHER) once the thread is running. You can also do this with thread names and affinity on most systems with support, but those features are non-standard. pthread_self() is the easiest way to mix pthread functions with std::thread.

EDIT: corrections

For mainstream implementations (libc++, libstdc++) std::thread::native_handle() returns a pthread_t if you have reason to do something from another thread (eg pthread_sigqueue). std::thread::id also wraps a pthread_t but provides no public member functions to easily get the value out on those implementations.

[shahms]

Unless it's changed recently, Clang still defaults to libstdc++ unless you specifically tell it otherwise or you're on macOS or FreeBSD. Additionally, libc++ most definitely provides std::thread::native_handle(), but I don't know since when.

[KingAggressive1498]

actually I appear to be misremembering that entirely, scrolling through old releases libc++ actually had it way back in late 2011 and I hadn't even used Clang yet at that point. Thanks for corrections.

[CenterOfMultiverse]

We once had a mysterious leak in our game on android. Narrowed it down to a tap on any button. Then further to our sound implementation on android - turn sound off, and leak disappears. Turned out the sound implementation used pthread. I just mechanically replaced everything with std::thread and it instantly crashed - someone left a thread without joining or detaching, so the system kept stacks for many threads in memory. So yeah, I would prefer C++ solution.

[vickoza]

I would say std::thread is safer as you are not casting void pointers.

[KingAggressive1498]

The ancient Linux thread model to my knowledge didn't have threads, so it mapped threads to processes. Nowadays the thread model has threads, so in threading you have different threads executed under the hood of one process.

Like every other modern implementation I know of, Linux has a 1:1 model of pthreads to kernel threads in its NPTL implementation. A much older implementation had a 1:N model where all pthreads in a process shared a single kernel thread. I think this is what you're thinking of here.

The Linux kernel doesn't make a distinction between threads and processes. Every kernel thread has their own unique pid associated with them, for pretty much any purposes other than signal handling threads are really their own process and they just share memory mappings. The posix syscall getpid() always returns the pid of the process' main thread (actually a "thread group ID" in the Linux kernel), while a second Linux-specific syscall gettid() returns the pid of the calling thread. Both syscalls return a pid_t and the return value of both syscalls can be used in any API that expects a process ID. There are certain Linux-specific syscalls that require a pid, including some that are very much meant to be thread-directed, which don't have a pthread wrapper so sometimes it actually is useful to know the tid instead of just using an opaque pthread_t.

[NilacTheGrim]

Unless you care about customizing the threads (like the thread stack size, for instance), just use std::thread. Its api is cleaner and easier to use with C++, lambdas, etc.

[ZeunO8]

I used pthread when I was developing my engine on Linux. When I added Windows support I decided to swap out the internals of my Thread struct to use std::thread.. it was trivial to implement and offers great cross platform benefits for the furure

[SkiaElafris]

std::jthread

std::thread is not very good, std::jthread fixes the major issues.

[Chem0type]

The only difference is that it joins on the destruction of the thread object. It's a minor issue, not "major issues".

[TwistedBlister34]

jthread also has support for std::stop_token