dennis said:
@Fab: Great analysis. My observation is that the only time I run into problems is when the control system is trying to do more than one thing at a time. Case in point this morning, when I was backing out of the garage and accessing the audio at the same time. The front parking sensors kept beeping for my entire drive to the gym, apparently because I was trying to change the audio at the exact moment the system determined that the parking sensors were now out of range.
It appears that the control system either misses events or gets interrupted out of processing events and as a result the state machine gets confused. The only way to clear this is to turn off the car and wait for the computers to reset.
...
This pretty much confirms my initial suspicions: the guys who wrote the software have no experience in dealing with parallel processing / multitasking.
This is not terribly surprising since most non-OS programmers don't, and even a large number of OS programmers can't seem to get the hang of using mutual exclusion (especially if it's via low level items like semaphores, condition variables, and mutexes). Which is why good OS interfaces largely provide other programmers the illusion of "pure ownership" of each interface (e.g., each program that tries to emit audio thinks it has sole control of the audio system, by default, when in fact the various audio parts get mixed through /dev/audio or whatever the name is for the default audio interface).
In some special cases one wants programs to be able to suspend other programs, or mute other users of the audio, etc.; then the interfaces get hairier.
