VM obsolescence -> multi threading thoughts.
Posted: Thu Jun 01, 2006 12:29 pm
This message grew from reply to the following quote, but got long enough that it wouldn't fit into the same message with the on-topic part, and I thought I'd be offtopic enough to warrant it's own thread.
This is also why writing well behaving graphical applications is often so hard, and why writing web-based program are even harder. In languages with C-style control flow, you have to write your code to handle the events. In a language where you have direct support for closures, or co-routines or something, you could write direct code for operations, and have the system interleave it with an event-loop for you, basicly giving you co-operative multi-threading within a single process.
There is one good use for multi-threading though: you can run on several processors at the same time. Now that I think of it, there's no fundamental reason why you couldn't specify some constraints on which events are allowed to execute at the same time, and have the event-loop automatically dispatch events on several processors. Logical question would be: how does this differ from normal multi-threading?
Well, since you have to prepare for any (valid) order of events anyway, you need a consistent global state between the events. Since pure event-based processing never blocks, except when waiting for more events, you only need to figure out which events rely on the same mutable state, and ask the system to serialize those events. This will temporarily degenerate the system into uni-threading model (especially if events can't be reordered) but at least it'll never deadlock: nobody is waiting for anything, we are just serializing things that aren't safe concurrently.
I think this a pretty interesting idea. Event based "concurrency" is pretty easy to reason about (even when hard to write on C-style languages) since it's explicit, so adding true concurrency as an optimization shouldn't complicated matters much.
I think I'll have to write a small language that implement the above. I think it has some potential.
I think multithreading is highly overrated. I think the reason is that C and it's derivatives (including Java) make it so hard to do decent event-based processing; you basicly have to decompose your program into manual continuation passing style, which isn't exactly the most natural thing to write in a system without direct support for closures.AST's comments about swapping remind me of when he argued against multithreading 15 years ago.
This is also why writing well behaving graphical applications is often so hard, and why writing web-based program are even harder. In languages with C-style control flow, you have to write your code to handle the events. In a language where you have direct support for closures, or co-routines or something, you could write direct code for operations, and have the system interleave it with an event-loop for you, basicly giving you co-operative multi-threading within a single process.
There is one good use for multi-threading though: you can run on several processors at the same time. Now that I think of it, there's no fundamental reason why you couldn't specify some constraints on which events are allowed to execute at the same time, and have the event-loop automatically dispatch events on several processors. Logical question would be: how does this differ from normal multi-threading?
Well, since you have to prepare for any (valid) order of events anyway, you need a consistent global state between the events. Since pure event-based processing never blocks, except when waiting for more events, you only need to figure out which events rely on the same mutable state, and ask the system to serialize those events. This will temporarily degenerate the system into uni-threading model (especially if events can't be reordered) but at least it'll never deadlock: nobody is waiting for anything, we are just serializing things that aren't safe concurrently.
I think this a pretty interesting idea. Event based "concurrency" is pretty easy to reason about (even when hard to write on C-style languages) since it's explicit, so adding true concurrency as an optimization shouldn't complicated matters much.
I think I'll have to write a small language that implement the above. I think it has some potential.