I was making some changes to code to run OpenWRT and created an intermittent SEGV. The code has calls to pthread_mutex_(un)lock() in it and I thought it might be a threading issue around memory management, and the resources not being locked properly.
To help see what was happening I added a bit of debug code to see if different thread IDs were showing up from pthread_self(). However, I only ever see one ID even though I know different callbacks are being launched by timers, ubus, etc.
Is the "lack" of threads a known feature of some / most / all OpenWRT platforms or am I misinterpreting things? For example, if I built an x86 OpenWRT and ran the same code there would I see "proper" threading?
If threads on typical OpenWRT platforms are wholly non-premptive does that mean using mutex is unneccesary and also hard to test - but leaving out resouce locks could lead to problems for the code on other platforms?
OpenWrt uses musl libc which in turn has complete and functional support for POSIX threads (pthreads). I assume your code has issues. Maybe it relies on glibc specific semantics which work differently with musl libc.
I think the SEGV may in fact be unrelated to threads.
I understand that the pthreads library is there and "does no harm". What I'm wondering is if OpenWRT on a typical SoC device uses threads in such a way that multi-threading issues could ever show up.
OpenWRT is perfectly capable of using threads, and there's nothing wrong with OpenWRT's thread support. It's just a Linux distro. Your router is just a Linux computer with several ethernet ports.
Agreed, in the sense that the code will behave correctly. But the question is whether OpenWrt is preemptive enough on any / all chipsets that resource locking is needed. If all the pthread calls were removed would it still work?
The musl libc features a complete and functional pthread implementation that runs correctly written code in parallel, it's not just a stub doing nothing.