Re: how to use volatile key word?
scott@slp53.sl.home (Scott Lurndal) wrote in
news:ONKGr.39377$C06.11961@news.usenetserver.com:
Paavo Helde <myfirstname@osa.pri.ee> writes:
Juha Nieminen <nospam@thanks.invalid> wrote in
news:jse5si$c7s$1@speranza.aioe.org:
Paavo Helde <myfirstname@osa.pri.ee> wrote:
Volatile is meant to be used for accessing memory-mapped hardware,
if you are not writing device drivers or such you can just forget
about it. It is neither needed nor sufficient for portable thread
synchronisation.
'volatile' might not be sufficient for thread synchronization nor
atomicity, but it can certainly make a difference in a multithreaded
program.
In a program I had a case where I was just reading an integral from
one thread that was changed by another thread to signal a minor,
unimportant effect (namely something related to updating the UI).
This did not require full-fledged locking (which would have made it
needlessly expensive) because if the integral had a wrong value for
a split second, that wasn't really a catastrophical event.
Out of curiosity - did you measure how much the "needlessly expensive"
locking was slower than using a volatile? I'm asking because I find
myself often in urge to invent all kind of clever tricks to bypass
proper locking.
This will be dependent on how the volatile is used. For example:
volatile bool Class::terminate_thread = false;
.
.
.
void
Class::Run(void *arg)
{
while (!terminate_thread) {
// do something
}
pthread_exit(NULL);
}
.
.
.
If terminate_thread is declared volatile (since its value can be
changed by another thread or a signal handler), the effect on code
generation is minimal (a load each time through the loop instead of
using a register cached value), while most synchronization mechanisms
will require at least one function call.
Given that accesses to 'bool' datatypes are atomic on most modern
architectures, it is a common paradigm to use volatile on such
variables.
I agree this is probably working fine with current systems, but I think
it is not guaranteed to work by any standard, is it? If so, it may
arguable cease working on some not-so-distant future hyper-super multi-
core machine.
Anyway, I believe these saved cpu cycles are worth something only if the
loop is really very tight and fast, but 'volatile' does not guarantee an
immediate notification anyway so it does not really make sense to check
the flag so often. In such a tight loop, why not check the flag e.g. each
1000-th iteration with proper locking?
Cheers
Paavo