[cpp-threads] Web site updated

[Boehm, Hans]

> -----Original Message-----
> From: Paul E. McKenney [mailto:paulmck at linux.vnet.ibm.com] 
[Lots deleted.]
> 
> By "device driver code", you are including the increasingly 
> common case of device drivers that run within user applications?
Yes, I am also excluding that if it uses different kinds of memory
mappings from standard process memory.  I think we at least potentially
have to.  Aside from the standards issues, if different kinds of fences
etc. are required to order the memory accesses to device registers, we
certainly don't want to require the compiler to always generate those
fences just in case device memory is involved.

For older PowerPCs at least, this really does seem to be an issue.
According to the old (and now somewhat corrupted) web page at
http://www-128.ibm.com/developerworks/eserver/articles/powerpc.html,
lwsync does not do anything useful on device memory.  I expect similar
statements hold for other architectures.

> 
> The whole point of this effort is to provide definition to a 
> class of C/C++ programs that involve parallelism, and that 
> therefore break (or at least severely bend) the sequential 
> model that C/C++ has been based on for some decades.  Some 
> constraints on optimization come naturally with this territory.
> 
My goals are really weaker than parallelism in general.  I'd like a good
definition that allows reliable and portable user-level threads programs
to be written, since that's what a lot of people will be faced with on
multicore processors.  And I'd like to do this in a way that avoids
making any other form of parallelism harder, making it easier if at all
possible.  But I'm not convinced we can solve all of those problems at
once.

The vaguely related issue of separate processes with shared memory
segments has also come up previously.  I think de facto we have also
decided to address that only partially.  Well-defined atomics and a
memory model should directly help there.  But we are not addressing
other issues required to solve the problem.  For example, I believe
we're not defining which shared library objects may be safely placed in
shared memory and accessed from another process.  (It better not contain
a vtable, function pointer, or statically allocated data reference for
this to work.)

Hans