9 ms·

"Unix SMP" is not synonymous with a system threading interface -- processes give parallelism as well and predate the introduction of threading interfaces. The p

"Unix SMP" is not synonymous with a system threading interface -- processes give parallelism as well and predate the introduction of threading interfaces. The pthread interface came about in the 1990s. The unix interface is broken with respect to threads in many places besides this. Signals. Forking. Problems abound because the concept was bolted on decades later.

mmt 8y ago
> processes give parallelism as well and predate the introduction of threading interfaces Right, but the reverse isn't true, which is what I was getting at. That is, availability of hardware parallelism was a prerequisite for anyone wanting threading in the first place.
- MaxBarraclough 8y ago
  I don't get you. Are you saying that the only reason people would want threading capabilities is to exploit multicore/multiprocessor architectures? That isn't true. Having multiple threads for GUI applications makes sense for responsiveness even on a single-core machine.
  - mmt 8y ago
    > Are you saying that the only reason people would want threading capabilities is to exploit multicore/multiprocessor architectures? That's exactly what I was saying, though, specifically, kernel threading support. > Having multiple threads for GUI applications makes sense for responsiveness even on a single-core machine. I had never heard this before, but I'm hardly an expert. Is there something you could point to, ideally pre-MP (or pre-MP-popularity), that advocates for kernel thread support being needed for improved GUI responsiveness.
    - MaxBarraclough 8y ago
      Strictly speaking you're right, it's not really about kernel threads. It's about concurrency. Proper pre-emptive threads in the kernel aren't the only way to achieve that: Java used to use 'green threads' rather than kernel threads. Its advice on using worker threads to keep your Swing application nice and responsive [0], would still have applied. (I believe this is still the case today for GTK programming in Python, which still uses green threads.) Most GUI toolkits use C-based languages and compile to native code. Cooperative multithreading isn't a popular model in C-family languages, but I can't see a good technical reason that it wouldn't work (after all, it boils down to something akin to green threads with finer control). A well-designed Qt app (in C++) will use worker threads to keep the UI thread responsive [1]. It doesn't matter if the worker threads run on a different core, or on the same core through time-division multiplexing. It's not a question of compute-throughput. What matters is that the UI thread doesn't get blocked for long. [0] https://docs.oracle.com/javase/tutorial/uiswing/concurrency/index.html https://docs.oracle.com/javase/tutorial/uiswing/concurrency/... [1] https://doc.qt.io/archives/qq/qq27-responsive-guis.html https://doc.qt.io/archives/qq/qq27-responsive-guis.html
      - 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.
kazinator 8y ago
signals, forking, and simple things like chdir. A huge area that is broken w.r.t. threading is the whole internationalization stack: setlocale and all. What if I want to write a server such that each request is executed in a potentially different locale (because it services globally distributed users?)
- throwaway76543 8y ago
  Ah yes, I was thinking about the system call interfaces but if we start looking at libc damn near nothing was reentrant until relatively recently (the late 90s and early 00s count as recent right? ... right?) Just take a gander at all those _r functions where an extra parameter needed to be added for reentrancy.
  - kazinator 8y ago
    Some of them turned out to be hyper-corrective duds, like readdir_r. No need for that one, since the buffer it needs can be allocated in the DIR object. You'd never want multiple threads concurrently doing readdir_r from the same DIR stream; there is no credible use case for it. (Or, maybe, optimization? Since it can store the dirent-s directly into some space designated by the caller, eliminating a copy operation from a program that wants to retain all those dirent-s.)
    - throwaway76543 8y ago
      Is this because, as I recall, a DIR object is opaque while a FILE is not? Allowing the former to be expanded without breaking the API? edit: Nevermind, that shouldn't matter should it? The important thing is that they're both by reference.
      - loeg 8y ago
        FILE can be opaque. Some implementations made the (arguable) mistake of implementing e.g. fileno() as a macro that accesses FILE internals, and this means they can't change that layout without breaking libc ABI of existing programs. But you can implement all POSIX stdio FILE APIs with an opaque FILE.

mmt 8y ago

> processes give parallelism as well and predate the introduction of threading interfaces Right, but the reverse isn't true, which is what I was getting at. That is, availability of hardware parallelism was a prerequisite for anyone wanting threading in the first place.

MaxBarraclough 8y ago
I don't get you. Are you saying that the only reason people would want threading capabilities is to exploit multicore/multiprocessor architectures? That isn't true. Having multiple threads for GUI applications makes sense for responsiveness even on a single-core machine.
- mmt 8y ago
  > Are you saying that the only reason people would want threading capabilities is to exploit multicore/multiprocessor architectures? That's exactly what I was saying, though, specifically, kernel threading support. > Having multiple threads for GUI applications makes sense for responsiveness even on a single-core machine. I had never heard this before, but I'm hardly an expert. Is there something you could point to, ideally pre-MP (or pre-MP-popularity), that advocates for kernel thread support being needed for improved GUI responsiveness.
  - MaxBarraclough 8y ago
    Strictly speaking you're right, it's not really about kernel threads. It's about concurrency. Proper pre-emptive threads in the kernel aren't the only way to achieve that: Java used to use 'green threads' rather than kernel threads. Its advice on using worker threads to keep your Swing application nice and responsive [0], would still have applied. (I believe this is still the case today for GTK programming in Python, which still uses green threads.) Most GUI toolkits use C-based languages and compile to native code. Cooperative multithreading isn't a popular model in C-family languages, but I can't see a good technical reason that it wouldn't work (after all, it boils down to something akin to green threads with finer control). A well-designed Qt app (in C++) will use worker threads to keep the UI thread responsive [1]. It doesn't matter if the worker threads run on a different core, or on the same core through time-division multiplexing. It's not a question of compute-throughput. What matters is that the UI thread doesn't get blocked for long. [0] https://docs.oracle.com/javase/tutorial/uiswing/concurrency/index.html https://docs.oracle.com/javase/tutorial/uiswing/concurrency/... [1] https://doc.qt.io/archives/qq/qq27-responsive-guis.html https://doc.qt.io/archives/qq/qq27-responsive-guis.html
    - 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.

kazinator 8y ago

signals, forking, and simple things like chdir. A huge area that is broken w.r.t. threading is the whole internationalization stack: setlocale and all. What if I want to write a server such that each request is executed in a potentially different locale (because it services globally distributed users?)

throwaway76543 8y ago
Ah yes, I was thinking about the system call interfaces but if we start looking at libc damn near nothing was reentrant until relatively recently (the late 90s and early 00s count as recent right? ... right?) Just take a gander at all those _r functions where an extra parameter needed to be added for reentrancy.
- kazinator 8y ago
  Some of them turned out to be hyper-corrective duds, like readdir_r. No need for that one, since the buffer it needs can be allocated in the DIR object. You'd never want multiple threads concurrently doing readdir_r from the same DIR stream; there is no credible use case for it. (Or, maybe, optimization? Since it can store the dirent-s directly into some space designated by the caller, eliminating a copy operation from a program that wants to retain all those dirent-s.)
  - throwaway76543 8y ago
    Is this because, as I recall, a DIR object is opaque while a FILE is not? Allowing the former to be expanded without breaking the API? edit: Nevermind, that shouldn't matter should it? The important thing is that they're both by reference.
    - loeg 8y ago
      FILE can be opaque. Some implementations made the (arguable) mistake of implementing e.g. fileno() as a macro that accesses FILE internals, and this means they can't change that layout without breaking libc ABI of existing programs. But you can implement all POSIX stdio FILE APIs with an opaque FILE.