[cpp-threads] memory model

[Alexander Terekhov]

On 4/28/05, Alexander Terekhov <alexander.terekhov at gmail.com> wrote:
> On 4/28/05, Doug Lea <dl at cs.oswego.edu> wrote:
> > Alexander Terekhov wrote:
> > > Please stay away from volatiles. Please. In C/C++/POSIX they have
> > > defined semantics that has really nothing to do with threads. Consider
> > > also that some implementation use volatile to control granularity
> > >
> > > http://www.tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/V51_HTML/ARH9RBTE/DOCU0007.HTM#gran_sec
> > > http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51_HTML/ARH9RBTE/DOCU0008.HTM
> > >
> > > and requiring them to add barriers would not fly I'm afraid.
> >
> > I don't see any unsolvable probelms here.
> 
> And how would you solve it?
> 
> >
> > >
> > > C/C++ volatiles are already quite messy and extending that mess
> > > with (heavy) msync is NOT good, I believe.
> > >
> >
> > Please propose an alternative that is at least as usable for
> > common usages for an average programmer. We don't know of any.
> 
> Well, try
> 
> http://www.google.de/groups?threadm=EN7u9.8900%24Af5.345070%40newsfep2-win.server.ntli.net

That was about memory isolation issue. As for msync, atomic<>
(and perhaps atomic_pair<>) with explicit unidirectional constraints
on competing operations plus a few bidirectional msync::{*}fence() 
functions is the way to go, I believe.

http://www.google.de/groups?selm=4157CFA9.31445113%40web.de

regards,
alexander.