3 ms·
For those unaware of the finer nuances of native platform APIs, could you help shed a light on the difference between a “regular” thread and a pthread?
by josteink 8y ago
For those unaware of the finer nuances of native platform APIs, could you help shed a light on the difference between a “regular” thread and a pthread?
- gpderetta 8y agoMost threading related functions in posix are named with the pthread_* pattern, so pthread (short for posix threads) has become the name of regular (usually OS level) threads on a posix platform.
- jstimpfle 8y agoA "regular" thread I guess is whatever structure the OS has for parallel execution contexts. Sometimes they are subordinate to processes, i.e. a thread dies when its containing process dies and such. pthreads is a standardized API (part of POSIX) that exposes a particular notion of threads. On each platform, it's naturally implemented as a wrapper around whatever the OS can offer. Since it must be widely implementable and have an easy to use API, that also means that it's rather limited. As an example, if you don't want to use the pthreads API, I think on Linux you would use the Linux-specific clone() system call to create a thread (clone() is not part of POSIX). If you go down on that level you will find a wealth of additional Linux-specific thread-related tuning knobs.
- josteink 8y agoThanks for the detailed answer! So basically if I’m used to threads as a general cross-platform concept in higher level languages, I’m probably relating to pthreads?
- jstimpfle 8y agoI suppose it depends on what your concept of threads is. If you're designing a complex system, you're more likely to look at what platforms you must support, and then make up your own (less abstract) notion of threads such that it can be implemented on these systems and that it lets you take more advantage of the capabilities of these systems. I'd be surprised for example if Postgres used pthreads and not its own abstraction, supported by platform-specific implementations.