7 ms·

> 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. Th

by 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.
        anarazel 8y ago

by mmt 8y ago

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.
      - anarazel 8y ago