View Single Post
  #11   Spotlight this post!  
Unread 16-06-2014, 00:16
SoftwareBug2.0's Avatar
SoftwareBug2.0 SoftwareBug2.0 is offline
Registered User
AKA: Eric
FRC #1425 (Error Code Xero)
Team Role: Mentor
 
Join Date: Aug 2004
Rookie Year: 2004
Location: Tigard, Oregon
Posts: 486
SoftwareBug2.0 has a brilliant futureSoftwareBug2.0 has a brilliant futureSoftwareBug2.0 has a brilliant futureSoftwareBug2.0 has a brilliant futureSoftwareBug2.0 has a brilliant futureSoftwareBug2.0 has a brilliant futureSoftwareBug2.0 has a brilliant futureSoftwareBug2.0 has a brilliant futureSoftwareBug2.0 has a brilliant futureSoftwareBug2.0 has a brilliant futureSoftwareBug2.0 has a brilliant future
Re: Challenge problem: 'ladder of abstraction' iterative design in FRC

Quote:
Originally Posted by Colby Skeggs View Post
I am well aware of this "solution".
I said "reasonably implement". Your suggestion, as I truly hope you know, pegs CPU usage at 100% and consumes all available processing power. This is not reasonable, except in very specific use cases.

Also, if you try this on the cRIO under Java, you'll notice that it hangs every single thread other than the main thread for the duration, because Squawk does cooperative multitasking and this code has no "Thread.yield()". (It's still a bad idea in C++, of course, but not quite as horrendous.)
The cRIO's Java threading is cooperative? Ick! I'm tempted to go read the Java specification to see if that's even allowed.

EDIT: Went and read the Java spec. This does appear to be allowed. In particular, the sections where it mentions the "sleep" containts an implicit yield and the section where it says that having one thread "diverge" (aka infinite loop with no observable effects) means that all threads are allowed to do so. I am now very happy not to be writing Java.

Last edited by SoftwareBug2.0 : 16-06-2014 at 00:48.