Disabling interrupts to protect data

- C
- ChrisQ
  
  Contact options for registered users
Vote on answer
posted
14 years ago

Fri, Oct 30, 2009 10:44 PM

In this case no. It's a single threaded system + interrupts with no rtos where the interrupt state is never changed outside known boundaries. Within that we don't necessarily know the current state, hence the solution. Elsewhere, there's plenty of more conventional locks around queues etc, but the led driver section needed something a bit smarter, due to hardware constraints and other requirements. The overall software load is very high and would have preferred to have hardware dma support for the display driver, but there's unlikely to be any movement on that for a year at least.

Anyway, there are by now probably thousands of boards out there running this code without fault for a year or more, so I guess it must work :-)...

Regards,

Chris

- D
- David Brown
  
  Contact options for registered users
Vote on answer
posted
14 years ago

Sat, Oct 31, 2009 4:21 PM

That's a point worth thinking about - when dealing with these sorts of issues, you need to think about /all/ possibilities, and all places when interrupts could occur.

However, to change the interrupt state between these two instructions would require an interrupt routine that deliberately left interrupts disabled on exit, rather than restoring their prior state - that would definitely be a very unusual situation for an interrupt routine. For correctness of code like I posted, you simply have to disallow writing such an interrupt routine. Note that I'm talking about global interrupt enables here, as sometimes an interrupt routine will disable or enable particular peripheral interrupts.

But for lots of processors, you simply don't have that kind of operation. The only way you can get around it would be in cases when you know for sure that interrupts are enabled before you disable them - that way, you don't need to store the previous state.

- D
- David Brown
  
  Contact options for registered users
Vote on answer
posted
14 years ago

Sun, Nov 1, 2009 10:40 AM

I have a rule that any type consisting of more than two parts should be typedef'ed. That makes it a little easier to see when you are talking about a pointer to a volatile, or a volatile pointer, or whatever. However, "volatile" in itself is not always the best solution, since it might cause unnecessary memory accesses (as well as forcing the necessary ones).

I'm just point this out because cli/sti macros do not always act as memory barriers (/you/ may understand this, but others reading this thread might not). They are very commonly implemented with something as simple as "asm volatile ("cli")" - with gcc, that would not imply a memory barrier.

That brings up another good point - it is a good idea to check the generated code for such critical constructs. Compiler vendors are typically good, but they are not perfect. Sometimes in their quest for generating smaller and faster code, they make mistakes.