--- In AVR-Chat@yahoogroups.com, Bob Paddock <bob.paddock@...> wrote: > Volatile is never the solution to a problem with threads. Nonsense. The volatile attribute is precisely the solution for *any* situation where a variable can be changed by an outside actor - even if it is another task. As I noted, volatile doesn't address atomicity of access nor (as you alluded to) does it address serialization of resource access. Those are different problems with different solutions. Of course, you may argue that you should not design your system so that one task sits in a loop waiting for the value of a single-byte variable to be changed by another task. That's a different discussion altogether. If you do use this strategy, however, that variable *must* be volatile. --- In AVR-Chat@yahoogroups.com, Bob Paddock <bob.paddock@...> wrote: > I'd think really hard about casting [volatility] away as well. Indubitably. Tools of all kinds have proper and improper uses and may be dangerous if improperly used. It is not dangerous, for example, to cast away volatility in an ISR if no any other actor can change the variable in question. Whether the benefit of doing so outweighs the "costs" is a tradeoff decision like many others that must be made. Don Kinzer ZBasic Microcontrollers http://www.zbasic.net
Message
Re: gcc compiler bad behaviour
2012-04-14 by Don Kinzer
Attachments
- No local attachments were found for this message.