4 ms·

So they're waiting.

by d4ng 3mo ago

So they're waiting.

mgaunard 3mo ago
not really, they yield to other event sources, which is the opposite of waiting (which blocks forward progress and is a violation of real-time guarantees)
- DSingularity 3mo ago
  I think these things can be equivalent. It all depends on the definition of wait. The simple example can be x86 with monitor/mwait instructions. These will suspend a hardware thread until it can be awoken when the memory write happens to the monitored address. Nothing happens on that cpu thread in the meanwhile. Yet at the same time if things are being virtualized the higher authority exists and it can do something else with the CPU until the write. Same for OS type of event synchronization like Linux futex. I would argue that the wait abstraction is more powerful. The alternative isn’t powerful enough to enable these kinds of “wake me when I can be useful again” behaviors.
- d4ng 3mo ago
  The actor itself can be said to be waiting. When it yields, the thread is then able to run another actor which was waiting on a message, and which then has a message on the queue.
  - mgaunard 3mo ago
    That sounds like a misunderstanding of how the actor model works. An actor doesn't wait. It's an event-driven system, it doesn't get to own and decide when messages get fed to it.
    - d4ng 3mo ago
      Are there any actor system implementations that you know of that work differently?
      - mgaunard 3mo ago
        Well in mine for example, threads are pinned to a core and always spin, and actors are pinned to a given thread (you can have an arbitrary number of actors per thread, they're just objects), so "waiting" is certainly not something you'd use to describe the setup in any capacity.
        d4ng 3mo ago
        What happens when there are no messages on the queue for a given actor?
        mgaunard 3mo ago
        An actor does not have a queue; that's again the whole point I already made: it's event-driven, things are decoupled and the actor is not aware of how control flow happens. Regardless, when the queue which exists and is per-thread is empty, the program terminates.

So they're waiting.

by d4ng 3mo ago

So they're waiting.

not really, they yield to other event sources, which is the opposite of waiting (which blocks forward progress and is a violation of real-time guarantees)

DSingularity 3mo ago
I think these things can be equivalent. It all depends on the definition of wait. The simple example can be x86 with monitor/mwait instructions. These will suspend a hardware thread until it can be awoken when the memory write happens to the monitored address. Nothing happens on that cpu thread in the meanwhile. Yet at the same time if things are being virtualized the higher authority exists and it can do something else with the CPU until the write. Same for OS type of event synchronization like Linux futex. I would argue that the wait abstraction is more powerful. The alternative isn’t powerful enough to enable these kinds of “wake me when I can be useful again” behaviors.
d4ng 3mo ago
The actor itself can be said to be waiting. When it yields, the thread is then able to run another actor which was waiting on a message, and which then has a message on the queue.
- mgaunard 3mo ago
  That sounds like a misunderstanding of how the actor model works. An actor doesn't wait. It's an event-driven system, it doesn't get to own and decide when messages get fed to it.
  - d4ng 3mo ago
    Are there any actor system implementations that you know of that work differently?
    - mgaunard 3mo ago
      Well in mine for example, threads are pinned to a core and always spin, and actors are pinned to a given thread (you can have an arbitrary number of actors per thread, they're just objects), so "waiting" is certainly not something you'd use to describe the setup in any capacity.
      - d4ng 3mo ago
        What happens when there are no messages on the queue for a given actor?
        mgaunard 3mo ago
        An actor does not have a queue; that's again the whole point I already made: it's event-driven, things are decoupled and the actor is not aware of how control flow happens. Regardless, when the queue which exists and is per-thread is empty, the program terminates.