Comments on: Firmware-Specific Bug #1: Race Condition

By: Unintended Acceleration and Other Embedded Software Bugs « Barr Code

Unintended Acceleration and Other Embedded Software Bugs « Barr Code — Sun, 06 Mar 2011 12:20:22 +0000

[...] software control flow.” (Appendix A, p. 11) NASA also spent time simulating possible race conditions due to worrisome “recursively nested interrupt masking” (pp, 44-46); note, though, that [...]

By: IT student

IT student — Sun, 25 Apr 2010 20:28:53 +0000

Race condition could be the cause of Toyota’s unintended acceleration problems. The problem may be related to software controlled mutual exclusion as opposed to more expensive hardware controlled mutual exclusion. NASA had this problem in the late 70′s.

By: Miro Samek

Miro Samek — Wed, 03 Mar 2010 03:59:35 +0000

That’s an interesting observation. An event-driven framework can reduce (even eliminate) the need for sharing resources and replace it with sharing events that are managed by the framework in a thread-safe manner. Without sharing resources, race conditions won’t happen. However, event-driven paradigm is perhaps more vulnerable to deadlocks than traditional sequential programming style. If an event is lost or simply forgotten to be posted, the application might freeze. I plan to write about race conditions and such deadlocks in my “state space” blog. Stay tuned…

By: Ram C.

Ram C. — Thu, 25 Feb 2010 16:01:59 +0000

Now, if one were to use non-blocking event driven framework instead of a conventional OS/RTOS, would it not make life easier?

By: Ram C.

Ram C. — Wed, 24 Feb 2010 13:13:32 +0000

Great article on one of the trickiest class of problems for embedded engineers. Michael how about a follow up article on avoiding (by using good system design practices) or detecting and resolving deadlocks in code?

By: Anonymous

Anonymous — Thu, 18 Feb 2010 20:29:38 +0000

As both a hardware designer and a software designer I once had to debug a race condition in a corner case in the hardware. The target system was running in a mode where the control processor was running at a very high clock speed and the peripheral at a low clock speed (clock ratio were of course programmable).

First, the processor wrote to the peripheral instructing it to start. This command was buffered in the synchronziation logic between the clock domains. Then, the processor read the status flag. But the read signal was not synchronized. So the processor thought the peripheral was already finished (actually, it hadn't even started) causing the loss of the buffer of data the peripheral should be working on.

By: Anonymous

Anonymous — Thu, 18 Feb 2010 16:34:01 +0000

A common race condition I have seen involves communication between an ISR and main() or a task function by use of a global flag variable. The ISR sets the flag and the other code tests and then clears it.Too many developers either forget to disable the interrupt in main() or think the clear will always be atomic. Embedded programmers should never rely on the specific timings of instructions of their current processor.

By: Anonymous

Anonymous — Wed, 17 Feb 2010 15:54:01 +0000

Might mention deadlock as a possible result of all those mutexes. Can be alkmost as ahrd to fix as the problem they are introduced to solve.

By: Anonymous

Anonymous — Wed, 17 Feb 2010 08:33:07 +0000

Best practice: don't share data, encapsulate it in one thread only and provide a message-based interface to it.

By: J. Scott

J. Scott — Tue, 16 Feb 2010 19:00:59 +0000

Your definition of a race condition is too narrow in scope and doesn't address race conditions caused by an unexpected sequence of inputs.