Fw: [cpp-threads] Yet another visibility question

Michael Wong michaelw at ca.ibm.com
Wed Dec 20 13:35:57 GMT 2006


All, I would like to introduce Paul McKenney who is collaborating with the 
IBM team on C++ concurrency based on his background work on the Linux 
kernel. I have asked him to join this thread.

Michael Wong
XL C++ Compiler kernel Development
IBM Canada Ltd., C2/KD2/8200/MKM
8200 Warden Avenue
Markham, Ontario  L6G 1C7
W:905-413-3283 F:905-413-4839
C/C++ Compilers Support Page 
http://www.ibm.com/software/awdtools/ccompilers/support/
C/C++ Feature Request Interface 
http://www.ibm.com/support/docview.wss?uid=swg27005811
XL Fortran Compiler Support Page 
http://www.ibm.com/software/awdtools/fortran/xlfortran/support/
XL Fortran Feature Request Interface 
http://www.ibm.com/support/docview.wss?uid=swg27005812
----- Forwarded by Michael Wong/Toronto/IBM on 12/20/2006 08:31 AM -----

"Paul E. McKenney" <paulmck at linux.vnet.ibm.com> 
Sent by: cpp-threads-bounces at decadentplace.org.uk
12/19/2006 10:08 PM
Please respond to
paulmck at linux.vnet.ibm.com; Please respond to
C++ threads standardisation <cpp-threads at decadentplace.org.uk>


To
C++ threads standardisation <cpp-threads at decadentplace.org.uk>
cc

Subject
Re: [cpp-threads] Yet another visibility question






On Tue, Dec 19, 2006 at 08:44:21PM -0500, Doug Lea wrote:
> Peter Dimov wrote:
> >Boehm, Hans wrote:
> >
> >>We can argue about whether this should be considered a real
> >>dependency. But as I argued earlier with Peter, if we assume it
> >>isn't, I think dependency-based ordering becomes largely useless to
> >>the programmer, since I can't reason about it without looking through
> >>abstraction boundaries.
> >
> >I don't agree. Provable dependencies are not uncommon and in this case 
I
> >can use a raw/release atomic. Unprovable dependencies will need an
> >acquire. I can live with that.
> >
> 
> Maybe I'm not following this discussion closely enough, but it
> would seem that if you want to impose an ordering, then you
> should always state it, and then let the compiler worry about
> whether that actually requires a fence on the platform you run on?
> 
> In other words, the following would almost never be correct:
>   r1 = x.load_raw(); // should be load_acquire
>   r2 = *r1;
> And maybe tools could help find such errors.
> 
> Or am I missing the point?
> 
> The alternative of defining dependencies seems to me to
> be a losing battle, at least in C++.
> 
> -Doug

For whatever it is worth to this group, all of the parallel projects
I have been involved with have used explicit ordering directives.
But many of the projects also have rules against gratuitous ordering
directives -- the desire is to instead bury them in higher-level
primitives, such as locking, list traversal, atomic operations, etc.

                 Thanx, Paul

-- 
cpp-threads mailing list
cpp-threads at decadentplace.org.uk
http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.decadentplace.org.uk/pipermail/cpp-threads/attachments/20061220/9f0be37b/attachment.html


More information about the cpp-threads mailing list