On Wednesday, 30 April 2014 at 22:48:28 UTC, Andrei Alexandrescu
wrote:
On 4/30/14, 3:08 PM, John Colvin wrote:
On Wednesday, 30 April 2014 at 21:51:17 UTC, Andrei
Alexandrescu wrote:
On 4/30/14, 2:47 PM, John Colvin wrote:
On Wednesday, 30 April 2014 at 20:57:26 UTC, Andrei
Alexandrescu wrote:
Finally, immutable is sharable accross thread. That mean,
even if we
bypass the type system, that RC must be atomic for
immutable.
As they
convert automatically for co,st, that mean that all const
code will be
full of atomic increment/decrement. They are bad for the
CPU, and
cannot
be optimized away.
Good point. I see that as a problem, albeit a solvable one.
How? Having lock; instructions implicitly appearing in
normal looking
slice code is unacceptable.
I'm thinking e.g. non-interlocked refcounts go like 1, 3, 5,
... and
interlocked refcounts go like 2, 4, 6, ...
Then you do an unprotected read of the refcount. If it's odd,
then
it's impossible to having originated as an interlocked one.
So proceed
with simple increment. If it's even, do an interlocked
increment.
Andrei
I don't think I fully understand.
Either all RC changes for a given type need to be atomic or
none do, and
that information is given by the type (everything that is
immutable/const/shared). I don't see any feasible way of
escaping this,
or any advantage to a runtime convention like the odd/even
trick above.
An object starting as shared or immutable would always need to
be atomically refcounted. That information is statically known.
For those we'd initialize the refcount to 2.
An object starting as regular mutable would always be
refcounted non-atomically. That's also known statically. So
that constructor initializes the refcount to 1.
Then a const object would dynamically choose the approach to
refcounting depending on the counter's evenness.
Andrei
Ah ok, that makes sense.
