Re: how to use volatile key word?
scott@slp53.sl.home (Scott Lurndal) wrote in
news:jwMGr.43370$0I1.18968@news.usenetserver.com:
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).
Agreed.
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.
Atomicity is not a concern I think, but the cross-thread visibility of
changes might be.
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.
pthread_cond_wait() already involves mutex locking, so there is no reason
why the termination flag could not be protected by the same mutex.
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).
poll(2) gives out information about events related to each file
descriptor, so in this case the terminate_thread flag is not needed at
all. If one is so concerned about the performance that one wants to avoid
a proper locking of the termination flag then one should be worried about
accessing a volatile variable as well.
Yeah, probably I'm just nitpicking and volatile flag works fine in the
practice.
Cheers
Paavo