C When pthreads will work properly on FreeBSD?

Last time when I have tested FreeBSD a few years ago, threads created with pthread was still not able to utilize multiple CPU cores. This made me to permanently halt all software development for BSD.

Currently however I plan to restart some development for FreeBSD, and release binaries for BSD from my new game engine (which uses software rendering, therefore threads are required to have a good experience on modern computers).

When can I expect this 25 year old BUG to be fixed (no, it's not a feature, no, it's not normal behavior, despite what you read in 30 year old handbooks, we live in 2021).
 
Do you have any reference for that claim?

I often see processes use more than one core on my machine, and it's very unlikely they don't use the pthread interface to create their threads.
 
Your question is one for the mailing lists and irc, not here, but your incorrect attitude and assumptions might get you run out on the rails.
 
Still I have doubts about the background. There's only one possible reason for a thread created with pthread_create(3) to only run on the same core as its parent process/thread: If the threads in libpthread.so were PULTs (implemented independently in userspace).

I can't claim this was never the case, but it certainly isn't today.

BTW, I just verified with ps -H on a tool I wrote myself, where I'm sure it uses pthreads to create its threads, and sure enough, they show up, so they are kernel-level threads able to be scheduled on any core.
 
As i have noted in the post, my experience refers to multiple year old FreeBSD distributions. Thats why i asked, when it will be fixed. IF its already fixed, thats very very good, because then and only then i am willing to compile freebsd binaries.
 
I'd still be interested in a reference about when libpthread on FreeBSD didn't create kernel-level threads…

Although this doesn't violate any spec, it's pretty pointless with multi-core etc being predominant.
 
The version failed this for me was from about versions i have tested from ~2011 to ~2013 and all of the versions i have tested back then, suffered from this issue, i have tested them on real computer, and on virtual machines as well. I dont know if that was the failure of the kernel, the runtime library, the pthread version, or it was due to an other factor or circumistances. What i am going to do (probably next month) is to download the newest release, and install it to a virtual machine, and see whats going on.
 
I dont know if that was the failure of the kernel, the runtime library, the pthread version, or it was due to an other factor or circumistances.
If the kernel knows about a thread, it can schedule it on any core/cpu it likes. So, if this was an issue, it would mean the pthreads implementation was using PULTs (Pure Userlevel Threads, also called "Green Threads").

After a bit of research, I found kernel level threads were supported by FreeBSD's pthreads implementation as far back as FreeBSD 6. Reference: https://www.icir.org/gregor/tools/pthread-scheduling.html
The libpthread implementation uses M:N threading. Its default scheduling scope is PTHREAD_SCOPE_PROCESS, the default policy SCHED_RR, and the default priority is 15.

Assinging priorities to threads and mixing PTHREAD_SCOPE_PROCESS and PTHREAD_SCOPE_SYSTEM works as expected and described above. libpthread can utilize multiple CPUs regardless of the scope of the threads.

So, m:n threading means a mixture of kernel-level and user-level threads. This source also tells the contention scope default was PTHREAD_SCOPE_PROCESS back then. Maybe this is still the default, I don't know. At least, if you keep the default, this source suggests that a kernel-level thread isn't created for each single pthread, but only for a group of them. If you want to change that, use pthread_attr_setscope(3).

edit: analyzing my own little tool using pthreads, I found it doesn't link libpthread.so but libthr.so, which seems to use different defaults. At least, I didn't change any attributes and ended up with kernel-level threads only.

Maybe you explicitly linked libpthread.so with e.g. -lpthread? If so, you normally shouldn't do this anyways but just give the option -pthread to the compiler instead, which will do the "default" thing on every platform.
 
For sure he confuses OpenBSD with FreeBSD.
I think the OP is wrong with that too. Both OpenBSD and FreeBSD support threads absolutely fine. If I run 8 threads, they generally utilise 8 cores.

I have written a number of multi-threaded software rasterisers and FreeBSD vs Linux performance is almost identical.

OpenBSD is a little slower but still not horrendous. The only thing that I think I recall not quite working was OpenMP but pthreads are fine.
 
I think the OP is wrong with that too. Both OpenBSD and FreeBSD support threads absolutely fine. If I run 8 threads, they generally utilise 8 cores.

I have written a number of multi-threaded software rasterisers and FreeBSD vs Linux performance is almost identical.

OpenBSD is a little slower but still not horrendous. The only thing that I think I recall not quite working was OpenMP but pthreads are fine.

Nowadays, YES.

As far as I can remember, Theo had strong opinions and objections against multithreading for a long period of time because of security reasons, he gave up on this and allowed Multithreading and SMP only in the more recent years, while the implementation in FreeBSD goes back to 2001 — scroll down to topic 6. of the article from October, 2001 linked below:
 
obsigna, shkln, you two seem to imagine things, because for example i haven't mentioned openbsd in my post anywhere. when its about bsd i have never dealt outside freebsd and the now deceased debian kfreebsd (of course i am aware of other bsd distributions, i have tried them, but never considered to compile anything for them at the end).

also i think Zirias have found the issue.

yes, i always link with -lpthread, and never used -pthread (i wonder how the guy who messed up those code ended up getting contrib rights for an operating system, and why the hell the first one does not works?) i cant afford myself unlimited k+r costs to combine obscure bits and flags for days just for the sake of compiling for a niche userbase, i am not sure if i can roll out that binary if the threads are not behaving as its intended by default. if replacing -lpthread to -pthread fixes it, or if the newest distribution works properly with it out of the box, then i am willing to do the port of course, as then doing it will be relatively easy and painless. (but still far more than just recompiling it, as i will probably get other bugs elsewhere, and i would like to focus on those - for example joystick support, maybe possible problems with alsa emulation, different ifdefs, lacks of a few linux specific calls i use, and those are already a big task enough.. so do not think i am lazy)
 
Nowadays, YES.

As far as I can remember, Theo had strong opinions and objections against multithreading for a long period of time because of security reasons, he gave up on this and allowed Multithreading and SMP only in the more recent years, while the implementation in FreeBSD goes back to 2001
Yep, its a good point. Even now for SMP on OpenBSD you need to enable it via the hw.smp sysctl.
 
That's what you wrote. If you don't want to be interpreted in the most literal sense, you should speak with example code.
 
edit: analyzing my own little tool using pthreads, I found it doesn't link libpthread.so but libthr.so, which seems to use different defaults. At least, I didn't change any attributes and ended up with kernel-level threads only.

Maybe you explicitly linked libpthread.so with e.g. -lpthread? If so, you normally shouldn't do this anyways but just give the option -pthread to the compiler instead, which will do the "default" thing on every platform.

Shouldn't make a difference:
Code:
% ls -lh /usr/lib/libpthread.so
lrwxr-xr-x  1 root  wheel     9B 27 окт.   2019 /usr/lib/libpthread.so -> libthr.so
 
Shouldn't make a difference.
The old source I found suggests they were different implementations in the past, probably changed meanwhile.

Then I guess the default behavior nowadays is PTHREAD_SCOPE_SYSTEM.

For portable code, you shouldn't rely on it and set it explicitly anyways.

yes, i always link with -lpthread, and never used -pthread (i wonder how the guy who messed up those code ended up getting contrib rights for an operating system, and why the hell the first one does not works?)
It's a bad idea when you don't understand something to start with accusations and complaints.

Just linking a threading library was never enough to enable POSIX threads, that's why compilers support the -pthread flag. It's always, on any platform, what you should use, it will e.g. also set some macros, and of course pick the default libraries of the target platform that implement POSIX threads.

Bottom line here: you did something wrong and then complain about a "defect" in the OS.
 
Zirias: and now shkhln says it does not makes a difference

accusations - give me a doll, so i can show on it, where freebsd threads have touched me.
 
Shouldn't make a difference:
Code:
% ls -lh /usr/lib/libpthread.so
lrwxr-xr-x  1 root  wheel     9B 27 окт.   2019 /usr/lib/libpthread.so -> libthr.so
I saw the same. Out of curiosity, I quickly linked a bigger project of mine with the two options in order to compare the output:
With -pthread:
ls -l CyControl; sha256 CyControl
Code:
-rwxr-xr-x  1 root  wheel  1298832  1 Apr. 11:18 CyControl
SHA256 (CyControl) = c92d7905db01ecf1491d33ea01b5875a95e5bb2508086f386e6ef83fbdec1c08
With -lpthread:
ls -l CyControl; sha256 CyControl
Code:
-rwxr-xr-x  1 root  wheel  1298832  1 Apr. 11:21 CyControl
SHA256 (CyControl) = 6766b1a19eeb3e164bcd37ee3a376ace43f61e86ac13a13524ff29c4badb2904

So the size is exactly the same, but the hash differs. Do we have a quick & dirty binary diff in the base?
 
Back
Top