3 ms·

> 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? S

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

MaxBarraclough 8y ago
> what would be the point The point of my comment there was that I'm not sure what you meant by 'inapplicable'. It would work, right? As you say, it seems unlikely you'd ever want to use file locks for intra-process concurrency when you could just use the mutex machinery of your language's standard library. The use of green threads doesn't change things at all. > the challenge was time-sharing the scarce resource that was a CPU, not parallelism The question there is how pre-emption works, right? They're non-cooperative threads after all. If I understand correctly, Solaris used not to have a direct mapping from userland threads to kernel threads (I'm not sure how the multiplexing worked), but they later moved to a direct mapping (every thread really is backed by a kernel-managed thread). (I could be completely wrong about that, I just skim-read the 'Solaris Internals' book once.)
- mmt 8y ago
  > The point of my comment there was that I'm not sure what you meant by 'inapplicable'. Inapplicable to the context of the over-arching discussion, which is POSIX advisory file locks. These are not the "threads" you're looking for. >>> Are you saying that the only reason people would want threading capabilities is to exploit multicore/multiprocessor architectures? So, to recap, yes, I'm saying the only reason people would want kernel threading capabilities (the only threading capabilities applicable to the topic at hand) is to exploit multicore/multiprocessor architectures.
  - MaxBarraclough 8y ago
    > the only threading capabilities applicable to the topic at hand If we're going to discuss the merits of kernel threads, it doesn't make sense to do so in a vacuum. > I'm saying the only reason people would want kernel threading capabilities [...] is to exploit multicore/multiprocessor architectures Didn't we already discuss this? The answer is no. Preemptive multithreading of native-compiled code, is a popular concurrency strategy. I gave the example of Qt. GUI toolkits based on C/C++ could use userland-based cooperative multithreading to keep things responsive, but they don't. They use kernel threads, for reasons which have nothing to do with parallelism.
    - mmt 8y ago
      > Didn't we already discuss this? The answer is no. We did, but you never made the case for the answer being no, which means the answer is still yes. > GUI toolkits based on C/C++ could use userland-based cooperative multithreading to keep things responsive, but they don't. They use kernel threads That's descriptive, not normative. You haven't said why that's the case, or, more importantly, why, in the absence of kernel threads, someone would want them to exist only for GUI responsiveness types of use cases. Your earlier admission led me to believe they wouldn't: > 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).

by mmt 8y ago

MaxBarraclough 8y ago

> what would be the point The point of my comment there was that I'm not sure what you meant by 'inapplicable'. It would work, right? As you say, it seems unlikely you'd ever want to use file locks for intra-process concurrency when you could just use the mutex machinery of your language's standard library. The use of green threads doesn't change things at all. > the challenge was time-sharing the scarce resource that was a CPU, not parallelism The question there is how pre-emption works, right? They're non-cooperative threads after all. If I understand correctly, Solaris used not to have a direct mapping from userland threads to kernel threads (I'm not sure how the multiplexing worked), but they later moved to a direct mapping (every thread really is backed by a kernel-managed thread). (I could be completely wrong about that, I just skim-read the 'Solaris Internals' book once.)

mmt 8y ago
> The point of my comment there was that I'm not sure what you meant by 'inapplicable'. Inapplicable to the context of the over-arching discussion, which is POSIX advisory file locks. These are not the "threads" you're looking for. >>> Are you saying that the only reason people would want threading capabilities is to exploit multicore/multiprocessor architectures? So, to recap, yes, I'm saying the only reason people would want kernel threading capabilities (the only threading capabilities applicable to the topic at hand) is to exploit multicore/multiprocessor architectures.
- MaxBarraclough 8y ago
  > the only threading capabilities applicable to the topic at hand If we're going to discuss the merits of kernel threads, it doesn't make sense to do so in a vacuum. > I'm saying the only reason people would want kernel threading capabilities [...] is to exploit multicore/multiprocessor architectures Didn't we already discuss this? The answer is no. Preemptive multithreading of native-compiled code, is a popular concurrency strategy. I gave the example of Qt. GUI toolkits based on C/C++ could use userland-based cooperative multithreading to keep things responsive, but they don't. They use kernel threads, for reasons which have nothing to do with parallelism.
  - mmt 8y ago
    > Didn't we already discuss this? The answer is no. We did, but you never made the case for the answer being no, which means the answer is still yes. > GUI toolkits based on C/C++ could use userland-based cooperative multithreading to keep things responsive, but they don't. They use kernel threads That's descriptive, not normative. You haven't said why that's the case, or, more importantly, why, in the absence of kernel threads, someone would want them to exist only for GUI responsiveness types of use cases. Your earlier admission led me to believe they wouldn't: > 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).