Conference clt::cma

> BUT, you should never need to use "volatile" for any variable protected by a
> mutex. And, if you do, then the compiler did something bad, or the thread
> library failed to do something to prevent the compiler from doing something
> bad -- depending upon your point of view. Any implementation of POSIX threads
> that requires you to use "volatile" on shared data (protected by a mutex) is
> simply broken.

    I had relayed the info in .18 to the rest of my project and
    regarding the above, the following questions came up:

	Is this only true with "POSIX threads", or is this also true with
	DCE threads?  How about Solaris threads?

	And is this only true if the calling language is C, or does it
	also apply to C++?

    I personally had never run into a problem in *not* using
    volatile on data protected by a mutex, using DCE threads
    since back to the 1st release of DEC OSF/1, and ULTRIX
    before that (when it was still called POSIX draft or CMA).
    But maybe I've only been lucky?

The POSIX standard is specifically written so that an implementation that
required "volatile" for shared variables would be nonconforming. ("Illegal".)

The POSIX standard applies only to the POSIX 1003.1c-1995 thread interface,
and only to the C language.

So therefore, there's no "standard" requiring rational behavior from DCE
threads, or from UI ("Solaris") threads, or for the C++ language.

On the other hand, there are basically two categories of program behavior
that affect this -- the compiler's treatment of temporary variables, and the
hardware's treatment of cache memory coherence across hardware
synchronization. I doubt that it's practical to create SMP hardware that
wouldn't guarantee memory coherence across processors based entirely on the
synchronization instructions that would be used to implement a mutex. It
would be possible to build a "higher level" language than C that required
fewer and less conservative "sequence points" in variables, but I don't think
C++ is restrictive enough to allow it.

And, most importantly, any language that doesn't allow you to use threads
without something as heavy-weight as "volatile" simply isn't compatible with
threads -- and that would make it essentially useless for real programs,
because volatile is too expensive.

	/dave

Without having reread the foregoing notes...  (:-)

.23> Is this only true with "POSIX threads", or is this also true with DCE
.23> threads?  How about Solaris threads?

With one exception, this is true for DCE threads.  I expect it's the same for
Solaris threads, as well.

The exception is the case where the program is using different mutexes to
protect adjacent portions of memory which are smaller than the atomic access
size (e.g., bytes, on an EV4/EV5 Alpha).

.23> And is this only true if the calling language is C, or does it also
.23> apply to C++?

It should apply equally to basically any language (I think).

.23> I personally had never run into a problem in *not* using volatile on
.23> data protected by a mutex [...] maybe I've only been lucky?

I doubt it; more likely you don't try to "bit-bum", cramming fields into
bytes or booleans into bitfields.  While these practices may save memory,
they usually cost in performance (and other access problems, like the above),
and memory is MUCH cheaper than performance or correctness...  :-)


				Webb