4 ms·

Or MacOS before OSX or Oberon or Amiga OS or how multitasking was typically implemented in FORTH or ...

gpderetta 6y ago
Actually Amiga OS was fully preemptive. What it did lack was memory protection and any clear distinction between kernel and userspace.
- guenthert 6y ago
  You're right. I do remember now having discussed that more than 30 years ago with someone who actually owned an Amiga then. I also remember my puzzlement when I learned that Oberon chose to support only cooperative scheduling which seemed like a step back then already.
amelius 6y ago
Yes, since then we've moved away from cooperative multitasking, especially in cases where we needed low latency, such as in UIs. It is therefore a bit strange that the pattern has resurfaced lately, and has been heavily used in the implementation of UIs and webservers ... You could argue that in small systems (compared to OSes), you can keep latency under control, but systems tend to grow, and modularity of the systems works against this (modules don't need to know what other modules do or how long they take to finish their tasks).
- imtringued 6y ago
  Cooperative multithreading has lower overhead and latency than preemptive multithreading. I don't know what you are talking about. The problem with cooperative multithreading is that you have to yield manually which is a disaster for scheduling random applications but not a problem when used inside a single application where it is isolated from everything else.
  - guenthert 6y ago
    Cooperative multithreading might have lower overhead, as it saves the trips from and to kernelspace, if handled by the application and by that can be assumed to be more efficient, which might be significant when there is a high rate of thread scheduling events. I don't see how it improves on latency, i.e. the delay between an external stimuli and the expected reaction to it. The maximum latency for cooperative multi-threading is in the general case unbounded and hence unsuitable to low-latency applications, much less for real time application.
    - quietbritishjim 6y ago
      I'm not sure if this is what the parent was referring to, but one way that it might have lower latency is if you have multiple strands / threads dealing with different bits of the system, with queues to pass messages between them. In a truely threaded application, handing data from one to another using a queue requires the new thread to be scheduled by the OS (unless the target thread is so busy that it pops the item off the of the queue immediately after handling the previous item). In a single-threaded async design, if the workload is light then, after the first strand adds an item to the queue and yields control, the second strand might pop the item off and deal with it immediately in the same time slice.
      - deleted 6y ago
        [deleted]

Actually Amiga OS was fully preemptive. What it did lack was memory protection and any clear distinction between kernel and userspace.

guenthert 6y ago
You're right. I do remember now having discussed that more than 30 years ago with someone who actually owned an Amiga then. I also remember my puzzlement when I learned that Oberon chose to support only cooperative scheduling which seemed like a step back then already.

amelius 6y ago

Yes, since then we've moved away from cooperative multitasking, especially in cases where we needed low latency, such as in UIs. It is therefore a bit strange that the pattern has resurfaced lately, and has been heavily used in the implementation of UIs and webservers ... You could argue that in small systems (compared to OSes), you can keep latency under control, but systems tend to grow, and modularity of the systems works against this (modules don't need to know what other modules do or how long they take to finish their tasks).

imtringued 6y ago
Cooperative multithreading has lower overhead and latency than preemptive multithreading. I don't know what you are talking about. The problem with cooperative multithreading is that you have to yield manually which is a disaster for scheduling random applications but not a problem when used inside a single application where it is isolated from everything else.
- guenthert 6y ago
  Cooperative multithreading might have lower overhead, as it saves the trips from and to kernelspace, if handled by the application and by that can be assumed to be more efficient, which might be significant when there is a high rate of thread scheduling events. I don't see how it improves on latency, i.e. the delay between an external stimuli and the expected reaction to it. The maximum latency for cooperative multi-threading is in the general case unbounded and hence unsuitable to low-latency applications, much less for real time application.
  - quietbritishjim 6y ago
    I'm not sure if this is what the parent was referring to, but one way that it might have lower latency is if you have multiple strands / threads dealing with different bits of the system, with queues to pass messages between them. In a truely threaded application, handing data from one to another using a queue requires the new thread to be scheduled by the OS (unless the target thread is so busy that it pops the item off the of the queue immediately after handling the previous item). In a single-threaded async design, if the workload is light then, after the first strand adds an item to the queue and yields control, the second strand might pop the item off and deal with it immediately in the same time slice.
    - deleted 6y ago
      [deleted]