C++, volatile member functions, and threads - comp.programming.threads

Message from discussion C++, volatile member functions, and threads

Dave Butenhof

More options Jul 3 1997, 3:00 am

Newsgroups: comp.programming.threads

From: Dave Butenhof <buten...@zko.dec.com>

Date: 1997/07/03

Subject: Re: C++, volatile member functions, and threads

  Reply to author
  |
  Forward
  | Print
  | View thread
  | Show original
  | Report this message
  | Find messages by this author
  

I really should ignore this deepening rat-hole. But, OK, just one more
try...

Patrick TJ McPhee wrote:

> Later, he introduced his non-thread-safe member function as an example
> of this, but that's nothing to do with the original concept. So far
> as I can see, the original posting didn't mention optimisation, and
> the idea has nothing to do with optimisation.

They exhibit the same essential flaw, the same misunderstanding of "what
it all means". This is of course no surprise, since the EXAMPLE was
indeed an example of the CONCEPT. It was substantially easier, and more
direct, to explain why the example wouldn't behave correctly than to
work with the generic concept. But they're the same thing, and I don't
see how you could consider comments on the example "irrelevant" to the
concept it demonstrates.

And as for "optimization"... if one is not interested in "optimizing",
then one has no motive whatsoever to risk the ill will of memory systems
by avoiding a mutex where it's appropriate to use a mutex. Therefore,
the only conceivable motivation for Eric's CONCEPT and EXAMPLE is a
desire to optimize. Thus, while he may or may not have used the word
"optimize", it would have been pointless to ignore that aspect of the
post.

> So sure, let's all agree that we shouldn't assume certain operations
> will be done in a single instruction and are therefore safe. Let's
> assume that you have to provide for thread synchronisation if you're
> going to update shared objects. Now what about the original question.
> Why shouldn't these objects be considered volatile?

The use of "volatile" is not sufficient to ensure proper memory
visibility or synchronization between threads. The use of a mutex is
sufficient, and, except by resorting to various non-portable machine
code alternatives, (or more subtle implications of the POSIX memory
rules that are much more difficult to apply generally, as explained in
my previous post), a mutex is NECESSARY.

Therefore, as Bryan explained, the use of volatile accomplishes nothing
but to prevent the compiler from making useful and desirable
optimizations, providing no help whatsoever in making code "thread
safe". You're welcome, of course, to declare anything you want as
"volatile" -- it's a legal ANSI C storage attribute, after all. Just
don't expect it to solve any thread synchronization problems for you.

Because of this flaw in reasoning, Eric's EXAMPLE of his CONCEPT was
neither correct nor an optimization.

I'd like to stop beating this to death. It's not fair to Eric, who
merely had the misfortune to be someone (like probably 95% of everyone
else) who didn't understand the intricicies of SMP memory systems and
thread synchronization. He proposed a shortcut, he was corrected, and I
suspect he (and certainly I) would like to move on to other matters and
stop dragging this (and him) through the dust. Please?

/---------------------------[ Dave Butenhof ]--------------------------\
| Digital Equipment Corporation buten...@zko.dec.com |
| 110 Spit Brook Rd ZKO2-3/Q18 http://members.aol.com/drbutenhof |
| Nashua NH 03062-2698 http://www.awl.com/cp/butenhof/posix.html |
\-----------------[ Better Living Through Concurrency ]----------------/

Reply to author Forward