Valid use of volatile is indeed for a memory location updated by a signal handler in a single-threaded program, or DMA, or as you say, a hardware interrupt. It's been quite a few years since I did any of that.
In a threaded program any volatile usage is highly suspect without at least a comment to justify and indicate the source of the idiom (e.g. double checked locking which is now the standard idiom to initialize an instance variable since Java 1.5 fixed the flaw). Situations where synchronization is clearly overkill and volatile is obviously strong enough are actually quite rare.
It's just an odd little habit of mine to exploit that suspicion and misuse the underused and frequently misused volatile keyword to highlight an unfixed concurrency problem when reviewing code. It looks so blatantly wrong that I find it much harder to ignore than a mere FIXME comment, and it precisely identifies the broken variable.
volatile is mostly just a convenient shorthand for// FIXME concurrency issue.
Any attempt to use threads is broken until proven otherwise, and even then there is probably something still wrong with it.
Most revision control systems are broken, in that they only give you one chance to commit both the content and the accompanying message right first time at the same time. Even if he is capable enough to be the first person to realize that he made a mess, he cannot clean it up himself because ordinary developers don't generally have permission to suppress broken intermediate revisions and modify ill-considered log messages from previous check-ins, even if they haven't been seen let alone used by anyone else yet. If a little mess really bothers you, then how about doing something constructive to keep the system cleaner? Do people check in at the start of the day, or under pressure at the end of the day? How about upgrading the revision control workflow to include a template, checklist, "are you sure" confirmations, reviewing, and even some automated formatting and validation for the message and content?
It could be worth creating, finding or inventing something he could be blackmailed for if someone wanted to get rid of him, or to get publicity to sell the biography.
Slashdot Mirror
Valid use of volatile is indeed for a memory location updated by a signal handler in a single-threaded program, or DMA, or as you say, a hardware interrupt. It's been quite a few years since I did any of that. In a threaded program any volatile usage is highly suspect without at least a comment to justify and indicate the source of the idiom (e.g. double checked locking which is now the standard idiom to initialize an instance variable since Java 1.5 fixed the flaw). Situations where synchronization is clearly overkill and volatile is obviously strong enough are actually quite rare. It's just an odd little habit of mine to exploit that suspicion and misuse the underused and frequently misused volatile keyword to highlight an unfixed concurrency problem when reviewing code. It looks so blatantly wrong that I find it much harder to ignore than a mere FIXME comment, and it precisely identifies the broken variable.
volatile is mostly just a convenient shorthand for // FIXME concurrency issue.
Any attempt to use threads is broken until proven otherwise, and even then there is probably something still wrong with it.
Most revision control systems are broken, in that they only give you one chance to commit both the content and the accompanying message right first time at the same time. Even if he is capable enough to be the first person to realize that he made a mess, he cannot clean it up himself because ordinary developers don't generally have permission to suppress broken intermediate revisions and modify ill-considered log messages from previous check-ins, even if they haven't been seen let alone used by anyone else yet. If a little mess really bothers you, then how about doing something constructive to keep the system cleaner? Do people check in at the start of the day, or under pressure at the end of the day? How about upgrading the revision control workflow to include a template, checklist, "are you sure" confirmations, reviewing, and even some automated formatting and validation for the message and content?
It could be worth creating, finding or inventing something he could be blackmailed for if someone wanted to get rid of him, or to get publicity to sell the biography.