http://embeddedgurus.com/barr-code/2008/03/rtos-myth-3-mutexes-are-needed-at-the-task-level/ A Blog by Michael Barr Fri, 18 May 2012 17:16:50 +0000 hourly 1 http://wordpress.org/?v=3.3.1 http://embeddedgurus.com/barr-code/2008/03/rtos-myth-3-mutexes-are-needed-at-the-task-level/comment-page-1/#comment-33 Dan Fri, 14 Mar 2008 21:35:00 +0000 http://www.gfcdev.org/test-stack/2008/03/12/rtos-myth-3-mutexes-are-needed-at-the-task-level/#comment-33 Nice article... the last paragraph really resonated with me:<i>Note that mutexes are also necessary inside functions that control hardware through I/O registers, which are effectively global data structures.</i>Just got done debugging a client's project/product that we took over after client was left high & dry by another firm. One problem they were having was intermittent interrupt problems.Turns out the interrupt enable register was originally being accessed by a single task which handled the ethernet interface (and the only interrupt that was enabled/configured once the kernel was running.)Later a 2nd task was added to handle a serial interface, and under the right conditions, the tasks were clobbering each others' attempts to modify the IER.In other words, one task was just doing: IER |= foo1;and the other: IER |= foo2;and it's funny, the same comment above each one, something to the effect of: // Fold in foo bit to enable interrupt; // NOTE: use logical OR, not assignment, to make sure we don't alter the other bits in the IERWell, yes, use BITWISE OR, but on top of that.... protect the shared data [hardware register]!!!I'm not perfect, we've all made mistakes, but this just struck me as someone who develops in the kiddie pool, as opposed to having a deep understanding of the architecture of the whole system, how multi-tasking & pre-emption work, etc...There were a host of other problems as well, probably not too surprising based on this example...Guess I should be happy, things like this keep me employed.It's funny, I've been doing this for over 15 years, and I realize how much I learned in my first job by working with an outstanding engineering team (educated as EE, but was doing firmware/kernel/driver development since day 1 of employment.) Nice article… the last paragraph really resonated with me:Note that mutexes are also necessary inside functions that control hardware through I/O registers, which are effectively global data structures.Just got done debugging a client’s project/product that we took over after client was left high & dry by another firm. One problem they were having was intermittent interrupt problems.Turns out the interrupt enable register was originally being accessed by a single task which handled the ethernet interface (and the only interrupt that was enabled/configured once the kernel was running.)Later a 2nd task was added to handle a serial interface, and under the right conditions, the tasks were clobbering each others’ attempts to modify the IER.In other words, one task was just doing: IER |= foo1;and the other: IER |= foo2;and it’s funny, the same comment above each one, something to the effect of: // Fold in foo bit to enable interrupt; // NOTE: use logical OR, not assignment, to make sure we don’t alter the other bits in the IERWell, yes, use BITWISE OR, but on top of that…. protect the shared data [hardware register]!!!I’m not perfect, we’ve all made mistakes, but this just struck me as someone who develops in the kiddie pool, as opposed to having a deep understanding of the architecture of the whole system, how multi-tasking & pre-emption work, etc…There were a host of other problems as well, probably not too surprising based on this example…Guess I should be happy, things like this keep me employed.It’s funny, I’ve been doing this for over 15 years, and I realize how much I learned in my first job by working with an outstanding engineering team (educated as EE, but was doing firmware/kernel/driver development since day 1 of employment.)

]]>