[cpp-threads] Implicit Conversion for Atomics

[Paul E. McKenney]

On Mon, Jan 28, 2008 at 06:55:50PM +0000, Boehm, Hans wrote:
> 
> 
> > -----Original Message-----
> > From: cpp-threads-bounces at decadentplace.org.uk
> > [mailto:cpp-threads-bounces at decadentplace.org.uk] On Behalf
> > Of Paul E. McKenney
> > Sent: Sunday, January 27, 2008 4:15 PM
> > To: C++ threads standardisation
> > Cc: c++std-ext at accu.org; c++std-lib at accu.org
> > Subject: Re: [cpp-threads] Implicit Conversion for Atomics
> >
> > On Tue, Jan 22, 2008 at 12:28:18PM -0800, Herb Sutter wrote:
> > > Haven't read the proposal yet (I will!) but to comment on
> > this part as someone who's presenting it now:
> > >
> > > > > I'd also add that
> > > > >
> > > > >     Implicit Load Encourages SC-focused Presentations
> > >
> > > That's going to be true anyway, with or without implicit load. :-)
> > > Even nearly all the academic lock-free papers don't say where the
> > > fences/etc. should go and assume SC, and that's a far
> > higher audience
> > > bar than industry presentations.
> >
> > Which by the way is one reason that the academic lock-free
> > papers have had so little impact on practitioners -- the code
> > in those papers, even when free of other bugs, often fails to
> > run on real (non-SC) systems.  ;-)
>
> I'm not sure I'd agree with that assessment.  It seems to me that
> this is one of lots of issues, which I'd have a hard time prioritizing.
> Another major reason seems to be that these algorithms are often difficult
> to understand and adapt to the slightly different problems that people
> encounter in practice.  And when you add all the necessary details,
> the result may not perform acceptably, compared to the lock-based version.

I agree that these other issues you call out are also very likely
reasons for the lack of lock-free impact, and I would also have a hard
time prioritizing.  Then again, I did say that leaving out memory fences
was "one reason" rather than something like "the main reason".  ;-)

						Thanx, Paul