"Andy Venikov" <swojchelowek@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! :)
The esoteric thing is that this is a compiler specific extension, not something guaranteed by the language. Currently there are no threads at all in C++.
Note that the largest part of the MSDN document is clearly marked "Microsoft Specific". It is in that part the release and aquire semantics are defined.
[ comp.lang.c++.moderated. First time posters: Do this! ]