http://www.ddj.com/cpp/184403766 describes a pattern for using the volatile keyword to get compiler help with correct locking. Initially I thought it was a great idea, but in trying it on the qpid::cluster::Cluster class I found enough problems to go back to my usual style (1). In summary:
- It's not a common idiom, likely to confuse newcomers to code. Googling suggests the semantics of volatile are inherently confusing to many. - It's disabled by default: unless all instances of your class are declared volatile, the pattern does nothing. - The implicit choice of volatile/non-volatile overloads makes it possible to call the wrong function by accident if you dont understand the rules. - Volatile correctness has riple effect just like const correctness: all instances/references/pointers need to be properly volatile qualified. - Base classes with non-volatile virtual function: either you abandon the convention or volatile-qualify all the base class functions, which may not be correct in all instances. - boost::bind can't handle volatile member fns. - It may disable compiler optimizations that will affect performance. - The article is from 2001 but googling turned up no evidence of actual use today, so it doesn't seem to have caught on. (1) my usual style being: - all public member functions are thread safe. - use ScopedLock to acquire/release locks. - private, unlocked functions that are only intended to be called with the lock already held take a dummy extra paramater of type ScopedLock& The dummy ScopedLock& parameter marks functions that are not locked and also makes it hard to accidentally call them in an unlocked context.
