Remix.run Logo
stackghost 2 hours ago

Very interesting. I spent a large part of my career in aerospace and never considered this failure mode before. It makes me wonder: how long is the pathological code allocation time? A few seconds, at most? We're talking about flight identification codes that are normally assigned upon takeoff and change at most a handful of times during a flight.

I assume the "manual request" is an aircraft squawking 7700 or similar, but why does the system need to interrupt an in-flight allocation in the first place? Any controllers here have insight?

One would think it would be sufficient to do something single threaded like

    if(!highPriorityQueue.empty() {
        highPriortyQueue.processOne();
    } else if(!lowPriorityQueue.empty()) {
        lowPriorityQueue.processOne();
    }
or whatever, but they're not and I'm curious why.
benmmurphy 2 hours ago | parent [-]

there will be some other tasks in the system that need time guarantees around when they get scheduled for very important (safety?) reasons. so when these higher priority tasks show up the lower priority tasks get suspended.

if they could guarantee hard bounds on how long low priority tasks take to complete they could implement your scheduling algorithm. but i think in reality the low priority tasks are either not boundable or they if they do have a provable bound the bound is too high.

stackghost 2 hours ago | parent [-]

It’s my understanding that this subsystem that failed only allocates codes but I could be wrong there.

It doesn’t make sense to have other non-code allocation things competing for queue space with code allocations.

NetMageSCW 21 minutes ago | parent [-]

Not queue space but CPU resources.