[cpp-threads] Alternatives to SC

[Raul Silvera]

> Herb Sutter wrote:
>
> Because it's not as expensive as a lock, especially if you're just
> doing reads. For example, DCL is still a performance win. Right? As
> Hans wrote a few hours ago in another thread:
>
> > I think that something with performance similar to the current Java
> > volatile implementations is useful, since it adds no overhead on the
> > reader side, and just mandates expensive writes.  I agree that if we
> > cannot get hardware vendors to make an implementation along those lines
> > work reliably, we have a problem.
>
> Herb
>

It is not true that current Java volatiles (SC) add no overhead on the
reader side. The simple fact that reads must be done in program order
implies a LoadLoad barrier, which carries a performance penalty.
Furthermore, as several other people have mentioned already, SC requires
reads to wait for any writes observed from other threads to become globally
visible. This means you need a StoreLoad barrier before each read, which is
a major penalty.

In practice, at IBM we discourage the use of volatiles in java for this
very reason; frequently you are better off using critical sections, where
you can amortize the overhead over multiple memory operations.

As has been mentioned, this overhead may be partially hidden by hardware
speculation, but it is not clear that enough speculation to fully cover
this overhead is feasible, specially once you go to non-trivial memory
configurations.

>
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads