Falk Tannh=E4user wrote:

>
> No, a "volatile address" would be of type 'int* volatile'.
> Both '*(volatile int*)&b' and 'const_cast<int volatile&>(b)' denote
> lvalues constituting volatile-qualified access paths to 'b'.
>
> > it doesnt say
> > that the assignment to b is volatile. thats brings you back to castin=
g to
> > volatile int....
> >
> > (volatile int ) * (volatile int*)&i =3D 4;
>
> I think that '(volatile int)i' has never been an lvalue in C, and I'm
> almost sure it has never been in C++, although some compilers accepted
> it as a "creative extension", with the same semantics as '*(volatile in=
t*)&i'.
>
> Falk

Oh yes ! Silly me.
-Roshan

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"David B. Held" wrote:
>
> Alexander Terekhov wrote:
> > [...]
> > Well, LL/SC is actually superior to CAS (LL/SC is ABA-proof), but
> > is less portable than CAS. And i386 doesn't have CAS, BTW.
> > [...]
>
> That's interesting, because:
>
> http://www.research.ibm.com/people/m/michael/ieeetpds-2004.pdf
>
> claims that LL/SC is fairly watered down in practice.

Well, Alpha and MIPS aside for a moment, see

http://www.ibm.com/developerworks/eserver/pdfs/archpub2.pdf
(1.7.3 Atomic Update)

<quote>

One use of lwarx and stwcx. is to emulate a "Compare and Swap"
primitive like that provided by the IBM System/370 Compare and
Swap instruction; see Section B.1, "Atomic Update Primitives"
on page 39. A System/370-style Compare and Swap checks only
that the old and current values of the word being tested are
equal, with the result that programs that use such a Compare
and Swap to control a shared resource can err if the word has
been modified and the old value subsequently restored. The
combination of lwarx and stwcx. improves on such a Compare and
Swap, because the reservation reliably binds the lwarx and
stwcx. together. The reservation is always lost if the word is
modified by another processor or mechanism between the lwarx
and stwcx., so the stwcx. never succeeds unless the word has
not been stored into (by another processor or mechanism) since
the lwarx.

</quote>

regards,
alexander.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Jim Hyslop wrote:

> Dietmar Kuehl wrote:
> > The standardization committee is well aware of the existance of threads
> > and I doubt that it will reject a reasonable proposal adding threads to
> > C++ (although such a proposal probably will have to address how thread
> > support is to be implemented on systems not supporting threads).
>
> Implementing the support is quite trivial, actually. A system that does
> not support threads generates exactly the code that is required:
> nothing. It should be easy enough to recognize the MT features and just
> ignore them. I'd prefer ignoring MT features over generating an error,
> because with an error you don't have portable code: you have to wrap
> your code in ugly #ifdefs.
>

There are two parts to that ignoring versus compile time errors.
First the core language features for MT , and second Standard Library
portions.

Lets say the threads and locks related abstractions go into the header
<thread>
When users tries to #include <thread> in order to instantate threads and fire
off multiple
threads on a non-MT system, the compiler should preferrable to indicate a
clear
*compiler error* at compile time rather than at run time. This should be a
trivial to do
using compile time asserts.... on just not shipping a <thread> on that system
:-)

But in the case of core language features (like if they decided on new
keywords or
type modifiers or things of that nature) those obviously should be ignored at
compile time
instead of issuing errors.

-Roshan

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Lo=EFc Joly wrote:
[...]
> If you give us an link to an article that explains that, instead of jus=
t
> vague allegations that Java does it better, then poeple will be able to
> read this article and there might be enough people to understand that.

http://www.cs.umd.edu/~pugh/java/memoryModel/jsr133.pdf
(Final Draft, August 19, 2004, 10:11am)

Eat carefully. The cake is hot. ;-)

regards,
alexander.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"David B. Held" wrote:
>
> Alexander Terekhov wrote:
> > [...]
> > Why would you need some barrier on increment?
>
> Thread 1 loads count from memory and increments it.  It gets written to
> cache but not to memory [yet].  Thread 2, on a different processor,
> loads the same count from memory and increments it.  They each write the
> same value to memory.  Are you saying this won't happen, and why?

Because each write is done using CAS or LL(LR)/SC.

regards,
alexander.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hyman Rosen wrote:
> > IMHO POSIX C++ binding is the way to go.
> >
> Concurrency must be defined by the language. It is
> impossible to add concurrency to C++ via nothing but
> a library.
>
 Sure. C++ standard must _allow_ for concurrent or simultaneous execution.
That's all.
 The remaining issues should be addressed by library...
--
         With all respect, Sergey.               http://ders.angen.net/
         mailto : ders at skeptik.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]