Several people have asked why I am so paranoid about tearing. This mail is
about tearing; there’ll be another about user model stacking and performance
models. (Please, let’s try to resist the temptation to jump to “the answer”.)
Many people are tempted to say “let it tear.” The argument for “let it tear”
is a natural-sounding one; after all, tearing only happens when someone else
has made a mistake (data race). It is super-tempting to say “Well, they made a
mistake, they get the consequences”.
While there are conditions under which this would be a reasonable argument, I
don’t think those conditions quite hold here, because from both the inside and
the outside, B3 classes “code like a class.” Authors will feel free to use
constructors to enforce invariants, and if the use site just looks like
“Point”, clients will not be wanting to keep track of “is this one of those
classes with, or without, integrity?” Add to this, tearing is already weird,
and while it is currently allowed for longs and doubles, 99.9999% of Java
developers have never actually seen it or had to think about it very carefully,
because implementations have had atomic loads and stores for decades.
As our poster child, let’s take integer range:
__B3 record IntRange(long low, int high) {
public IntRange {
if (low > high) throw;
}
}
Here, the author has introduced an invariant which is enforced by the
constructor. Clients would be surprised to find an IntRange in the wild that
disobeys the invariant. Ranges have a reasonable zero value. This a an
obvious candidate for B3.
But, I can make this tear. Imagine a mutable field:
/* mutable */ IntRange r;
and two threads racing to write to r. One writes IntRange(5, 10); the other
writes IntRange(2,4). If the writes are broken up into two writes, then a
client could read IntRange(5, 4). Worse, unlike more traditional races which
might be eventually consistent, this torn value will be observable forever.
Why does this seem worse than a routine long tearing (which no one ever sees
and most users have never heard of)? Because by reading the code, it surely
seems like the code is telling me that IntRange(5, 4) is impossible, and having
one show up would be astonishing. Worse, a malicious user can create such a
bad value (statistically) at will, and then inject that bad value into code
that depends on the invariants holding.
Not all values are at risk of such astonishment, though. Consider a class like:
__B3 record LongHolder(long x) { }
Given that a LongHolder can contain any long value, users of LongHolder are not
expecting that the range is carefully controlled. There are no invariants for
which breaking them would be astonishing; LongHolder(0x1234567887654321) is
just as valid a value as LongHolder(3).
There are two factors here: invariants and transparency. The above examples
paint the ranges of invariants (from none at all, to invariants that constrain
multiple fields). But there’s also transparency. The second example was
unsurprising because the API allowed us to pass any long in, so we were not
surprised to see big values coming out. But if the relationship between the
representation and the construction API is more complicated, one could imagine
thinking the constructor has deterred all the surprising values, and then still
see a surprising value. That longs might tear is less surprising because any
combination of bits is a valid long, and there’s no way to exclude certain
values when “constructing” a long.
Separately, there are different considerations at the declaration and use site.
A user can always avoid tearing by avoiding data races, such as marking the
field volatile (that’s the usual cure for longs and doubles.) But what we’re
missing is something at the declaration site, where the author can say “I have
integrity concerns” and constrain layout/access accordingly. We experimented
with something earlier (“extends NonTearable”) in this area.
Coming back to “why do we care so much”. PLT_Hulk summarized JCiP in one
sentence:
https://twitter.com/PLT_Hulk/status/509302821091831809
If Java developers have learned one thing about concurrency, it is: “immutable
objects are always thread-safe.” While we can equivocate about whether B3.val
are objects or not, this distinction is more subtle than we can expect people
to internalize. (If people internalized “Write immutable classes, they will
always be thread-safe”, that would be pretty much the same thing.) We cannot
deprive them of the most powerful and useful guideline for writing safe code.
(To make another analogy: serialization lets objects appear to not obey
invariants established in the constructor. We generally don’t like this; we
should not want to encourage more of this.)
There are options here, but none are a slam dunk:
- Force all B3 values to be atomic, which will have a performance cost;
- Deny the ability to enforce invariants on B3 classes (no NonNegativeInt, no
IntRange);
- Try to educate people about tearing (good luck);
- Put out bigger warning signs (e.g., IntRange.tearable) that people can’t
miss;
- More declaration-site control over atomicity, so classes with invariants can
ensure their invariants are defended.
I think the last is probably the most sane.
