Re: Robert Dewar's great article about the Strengths of Ada over other langauges in multiprocessing!

[Maciej Sobczak <see.my.homepage@gmail.com>]

On 13 Mar, 12:42, gp...@axonx.com wrote:

> OK, your point well taken, so it is up to compiler vendors to
> guarantee volatility under MT.

Vendors can (and should) provide you with some way to write correct MT
programs. This is an issue of normal competition on the market.
There are different ways to do it and language extension is one
possibility. If Microsoft claims that volatile works on their
compiler, it is language extension.

On the GNU side of the world the set of tools does not involve
volatile at all. Instead you get a set of POSIX interfaces that give
necessary guarantees related to memory consistency and visibility
(actually, POSIX gives them for C only, but this isn't a problem
except for standard lawyers).
Windows, as an operating system, provides similar guarantees with
similar interfaces (for example, pthread_mutex_lock in POSIX can be
compared to EnterCriticalSection on Windows). If you have a library
that abstracts the interface differences away (like Boost.Thread), you
can write portable software without any use of volatile. You don't
need volatile, because the system interfaces already provide the
necessary memory consistency and visibility guarantees. And since it
is possible to write portable software this way, it is what I would
recommend.

If you start using volatile relying on language extensions provided by
one particular vendor, you will not be able to easily port this
software to other platforms.

> Does it mean that original purpose of
> volatile ma not always hold either?

Original purpose of volatile did not relate to threads, so nothing
changes there.
To be exact (and to complete the discussion), the volatile type
specifier can be used to implement I/O, for information exchange with
signal handlers and for long jump. None of it is related to threads.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com