5 ms·

> Strictly speaking you're right, it's not really about kernel threads. I'm not particularly interested in being right or wrong, but, rather, improving underst

by mmt 8y ago

> Strictly speaking you're right, it's not really about kernel threads. I'm not particularly interested in being right or wrong, but, rather, improving understanding. The reason I made the (strict) distinction was that the whole discussion has been about kernel-supported file locking. Anything called "threading" outside of the kernel seems inapplicable, no matter how closely related conceptually or in practice. Of course, I may be missing something, such as if userspace/green threads both significantly preceded kernel threading support and motivated its implementation (presumably by benefiting from it).

MaxBarraclough 8y ago
> I'm not particularly interested in being right or wrong, but, rather, improving understanding. Sure, I hadn't meant to seem combative. > the whole discussion has been about kernel-supported file locking. Anything called "threading" outside of the kernel seems inapplicable, no matter how closely related conceptually or in practice Is it necessarily inapplicable? You could write a Python program that uses file-based locking, despite that Python threads don't map to kernel threads, no? Or in C, you could have 'fake threads' where you effectively bounce control around between a few different execution streams (something akin to coroutines or fibers). We could still reason about which 'thread' holds the file lock, despite that there's only one kernel thread. (Aside: the GNU 'Pth' library does something like this.) > such as if userspace/green threads both significantly preceded kernel threading support and motivated its implementation I think interpreters tend to use green threads simply for ease of implementation, more than for anything else. I suppose it helps with cross-platform concerns, but these days, it's quite possible to write multi-platform concurrent C/C++ code. Green threads aren't so popular today, now that multicore is the norm. Long ago, processes predated (kernel) threads. Before my time, but I believe the general idea then was that if you want the kernel to orchestrate concurrent execution (including executing in parallel on multiple cores if possible) then you'd just have to bite the bullet and go multi-process. Today we still see some use of process-level concurrency/parallelism, such as in Postgres.
- anarazel 8y ago
  > Today we still see some use of process-level concurrency/parallelism, such as in Postgres. FWIW, as somebody working on postgres, there's plenty reasons to regret this. The unshared memory, fd spaces make some things more complicated / heavyweight. We've cross-process shared memory allocators, but then the pointers all have to be relative. It's harder to separate connections from a "query execution context", making connections more heavyweight than necessary. Worker threads for async IO - which we'd love to have - would need to be duplicated in each process. Etc. There's still quite some benefits, like increased robustness in the face of bugs, reduced contention for memory alloccators etc, ... But I doubt you'd find anything close to a majority inside the postgres team to use threads if we'd need to make the decision again, unencumbered by existing code.
- mmt 8y ago
  > Is it necessarily inapplicable? You could write a Python program that uses file-based locking, despite that Python threads don't map to kernel threads, no? Sure, but what would be the point? I'm looking for legitimate motivations, not contrived examples of what's merely possible. Remember, we're talking about single-core, single-process, multi-threaded for responsiveness (e.g. in a GUI) here. That single process wants to use kernel file locking? > Long ago, processes predated (kernel) threads. Before my time, but I believe the general idea then was that if you want the kernel to orchestrate concurrent execution (including executing in parallel on multiple cores if possible) then you'd just have to bite the bullet and go multi-process. By the time Unix-based MP systems became common (all single-core at the time, just multi-socket), those OSes tended to have kernel threads and at least lightweight processes. I can't recall when SunOS 4.1 got it, but I think it was around '91 if not before, but Sun was pushing SunOS 5 aka Solaris 2 for their big SMP boxes https://www.dre.vanderbilt.edu/~schmidt/PDF/beyond_mp.pdf https://www.dre.vanderbilt.edu/~schmidt/PDF/beyond_mp.pdf Before that, there wasn't much biting of any bullets, as I recall, as the challenge was time-sharing the scarce resource that was a CPU, not parallelism. Frequent context-switching, process or even thread, would be the performance-killing worry for something real-time like a GUI on a computer with a single user. Per Moore's Law, today's CPUs have something like 11000x the transistor density of the ones in '91.
  - 8y ago

by mmt 8y ago

MaxBarraclough 8y ago

> I'm not particularly interested in being right or wrong, but, rather, improving understanding. Sure, I hadn't meant to seem combative. > the whole discussion has been about kernel-supported file locking. Anything called "threading" outside of the kernel seems inapplicable, no matter how closely related conceptually or in practice Is it necessarily inapplicable? You could write a Python program that uses file-based locking, despite that Python threads don't map to kernel threads, no? Or in C, you could have 'fake threads' where you effectively bounce control around between a few different execution streams (something akin to coroutines or fibers). We could still reason about which 'thread' holds the file lock, despite that there's only one kernel thread. (Aside: the GNU 'Pth' library does something like this.) > such as if userspace/green threads both significantly preceded kernel threading support and motivated its implementation I think interpreters tend to use green threads simply for ease of implementation, more than for anything else. I suppose it helps with cross-platform concerns, but these days, it's quite possible to write multi-platform concurrent C/C++ code. Green threads aren't so popular today, now that multicore is the norm. Long ago, processes predated (kernel) threads. Before my time, but I believe the general idea then was that if you want the kernel to orchestrate concurrent execution (including executing in parallel on multiple cores if possible) then you'd just have to bite the bullet and go multi-process. Today we still see some use of process-level concurrency/parallelism, such as in Postgres.

anarazel 8y ago
> Today we still see some use of process-level concurrency/parallelism, such as in Postgres. FWIW, as somebody working on postgres, there's plenty reasons to regret this. The unshared memory, fd spaces make some things more complicated / heavyweight. We've cross-process shared memory allocators, but then the pointers all have to be relative. It's harder to separate connections from a "query execution context", making connections more heavyweight than necessary. Worker threads for async IO - which we'd love to have - would need to be duplicated in each process. Etc. There's still quite some benefits, like increased robustness in the face of bugs, reduced contention for memory alloccators etc, ... But I doubt you'd find anything close to a majority inside the postgres team to use threads if we'd need to make the decision again, unencumbered by existing code.
mmt 8y ago
> Is it necessarily inapplicable? You could write a Python program that uses file-based locking, despite that Python threads don't map to kernel threads, no? Sure, but what would be the point? I'm looking for legitimate motivations, not contrived examples of what's merely possible. Remember, we're talking about single-core, single-process, multi-threaded for responsiveness (e.g. in a GUI) here. That single process wants to use kernel file locking? > Long ago, processes predated (kernel) threads. Before my time, but I believe the general idea then was that if you want the kernel to orchestrate concurrent execution (including executing in parallel on multiple cores if possible) then you'd just have to bite the bullet and go multi-process. By the time Unix-based MP systems became common (all single-core at the time, just multi-socket), those OSes tended to have kernel threads and at least lightweight processes. I can't recall when SunOS 4.1 got it, but I think it was around '91 if not before, but Sun was pushing SunOS 5 aka Solaris 2 for their big SMP boxes https://www.dre.vanderbilt.edu/~schmidt/PDF/beyond_mp.pdf https://www.dre.vanderbilt.edu/~schmidt/PDF/beyond_mp.pdf Before that, there wasn't much biting of any bullets, as I recall, as the challenge was time-sharing the scarce resource that was a CPU, not parallelism. Frequent context-switching, process or even thread, would be the performance-killing worry for something real-time like a GUI on a computer with a single user. Per Moore's Law, today's CPUs have something like 11000x the transistor density of the ones in '91.
- 8y ago