Challenge problem: 'ladder of abstraction' iterative design in FRC

[Cel Skeggs]

Originally Posted by SoftwareBug2.0

The cRIO's Java threading is cooperative? Ick! I'm tempted to go read the Java specification to see if that's even allowed.

I only figured this out by diving into the Squawk source code that I found online - so it's possible that the cRIO uses a majorly different version of Squawk, but I sincerely doubt it, especially as it matches all my observations and it seems difficult to change the concurrency model of Squawk. Luckily, this doesn't actually matter all that much in practice. The main location where it's annoying is when you're doing vision processing, because, at least with old versions of the FRC library, our vision processing could block other threads from running for ~100ms and cause major lag. Luckily, we changed our code so that we didn't have this issue, but it still wasn't very nice.

Originally Posted by SoftwareBug2.0

By the way efficiency is not relavent to the point that I was trying to make. And if you're doing cooperative stuff, then your implemenatation can just change to:

void sleep(float len){
    float start=get_time();
    while(get_time()<start+len) yield();
}

This still pegs your CPU, which as I mentioned earlier, is not relevant.

Actually, CPU usage here is completely relevant. Would you like to use a computer that's using almost all of its CPU on busywaiting? It would probably be slow, and there's certainly many better ways to do it. Busywaiting is a known antipattern. The only reason it could make sense is if you are sleeping for a very short amount of time.

I agree that this is a good solution, in some rare cases. I've even used it myself in bare-metal programming, when there's literally nothing else that the computer could possibly be spending its time. But it's not a good solution in this case. While it is a solution that "works", it is not a reasonable solution for this context.