"Andy Venikov" <swojchelo...@gmail.com> wrote in message
news:ho5s8u$52u$1@news.eternal-september.org...
I still must ask, really? That would mean that all shared
state must be volatile qualified, including internal class
members for shared data. Wouldn't that big a huge
performance hit when the compiler can't optimize any of
that? Could you even use prebuilt classes (which usually
don't have volatile overloads) in the shared data, like
say std::string, std::vector, std::map, etc.?
Not at all!
Most multi-threading issues are solved with mutexes,
semaphores, conditional variables and such. All of these
are library calls. That means that using volatile in those
cases is not necessary. It's only when you get into more
esotheric parallel computing problems where you'd like to
avoid a heavy-handed approach of mutexes that you enter the
realm of volatile. In normal multi-threading solved with
regular means there is really no reason to use volatile.
Esoteric? I would have thought independent correctly
aligned (and therefore atomic) x86 variable reads
(fundamental types) without the use of a mutex are not
uncommon making volatile not uncommon also on that platform
(on VC++) at least. I have exactly one volatile in my
entire codebase and that is such a variable. From MSDN
(VC++) docs:
"The volatile keyword is a type qualifier used to declare
that an object can be modified in the program by something
such as the operating system, the hardware, or a
concurrently executing thread."
That doesn't seem esoteric to me! :)
extension, not something guaranteed by the language. Currently
marked "Microsoft Specific". It is in that part the release