Re: how to use volatile key word?
Paavo Helde <myfirstname@osa.pri.ee> writes:
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.
Given the target for these applications, this is not a concern. It is
quite unlikely that any future computer architecture would fall over
on this anyway, for a number of reasons (including the mass of existing
legacy C and C++ code out there, for which volatile has certain meaning).
And I seem to recall some wording the the C standard about atomicity
guarantees for certain size data types, but all I have to hand is a 1988
draft document which says nothing.
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?
In the actual occurances, the loop includes one of:
- The poll(2) system call, waiting for work to arrive on one or
more file descriptors (e.g. an inbound network connection or inbound
packet) or
- A call to pthread_cond_wait(3), waiting for work to be queued to the
thread through shared memory.
The loop is anything but tight, and the "terminate_thread" variable is
checked once per "work item" (one of the file descriptors poll(2) is waiting
on is the read-end of a pipe used to break out of the poll(2) call when
the thread is being terminated).
scott