Egregoros · Phoenix Framework

Post

Remote status

Context

Zack Weinberg

CPU architecture in which there are no asynchronous interrupts, only hardware tasks that can be suspended waiting for an external event

Poll (single choice)

yes

12 votes 66.7%

6 votes 33.3%

better idea:

0 votes 0.0%

18 votes total · 18 voters Poll ended

David Chisnall (*Now with 50% more sarcasm!*)

@david_chisnall@infosec.exchange remote

@zwol

I also like this but voted no. Cambridge had a research architecture like this and I really liked it when I first saw it: architecturally, you have an unbounded (bounded by memory) set of hyperthreads. Microarchitecturally, you have a finite number and all runnable threads are pulled in when they can be. You can build a system with no register rename or speculation if you do this, which means it can get enormous (GPU-like) aggregate throughput.

The problems come when you want to provide scheduling policies. Think about how you’d implement a priority-inheriting mutex on such a system and you realise quite how complex a hardware-software interface you need. I’m willing to believe it’s possible but it’s a multi-year well-funded prototype to come up with something that actually addresses the hard problems.

Zack Weinberg

@zwol@masto.hackers.town remote

@david_chisnall I recall microkernels having similar problems with offering flexible scheduling policies, so that research seems like it might pay off in a bunch of directions.

David Chisnall (*Now with 50% more sarcasm!*)

@david_chisnall@infosec.exchange remote

@zwol Not really, microkernels usually have the scheduler in a single component, so flexible policies are easy. The difficulty they have is quite different: they want to account time spent in server A responding for a message from thread X in task B to thread X and task B. Spring had a good solution to this, but without it it’s easy to introduce priority inversion problems.

Zack Weinberg

@zwol@masto.hackers.town remote

@david_chisnall I have the impression Spring's solution rests on "doors" being synchronous. If I designed a microkernel it would be strictly asynchronous: all cross-domain invocations "just" queue a message and the *only* blocking operation is "wait for next message". Backpressure is achieved by charging senders for all messages in flight. I *think* this environment could handle priority inheritance by tracking the task priorities of all unacknowledged messages.

Only 3 Easy Payments of $19.95

@feld@friedcheese.us remote

@zwol @david_chisnall this sounds curiously like BEAM's process mailboxes

Replying to @feld@friedcheese.us

David Chisnall (*Now with 50% more sarcasm!*)

@david_chisnall@infosec.exchange remote

@feld @zwol

Beam is designed around the actor model (plus selective receive, which is why two-phase commit isn't too painful in Erlang but also why Erlang is not deadlock-free by construction). So it makes sense that it would look like another actor-model abstraction.

Replies

Fetching replies…