One of the prerequisites to doing reference counting is to have a mutable piece of data inside an immutable piece of data.

A few years ago, Timon Gehr implemented a concept for __mutable that looked like it might be the answer. But there was a large problem. As the title suggests, it's because immutable is implicitly sharable.

This makes sense in a world of fully transitive immutable, where if you have an immutable pointer, nothing in it can ever change. But if you have a __mutable island, that can change. So the answer at the time was, immutable(__mutable) -> shared.

Unfortunately, this means you have to apply it to const as well, because const could be pointing to immutable. I'll note that this still might be a valuable concept, just slightly annoying, especially with shared becoming more tightly controlled.

I thought of an idea -- maybe you make it so if a type T had a __mutable piece, you can't share an immutable(T). This actually works quite well, and now you have to explicitly have shared(immutable(T)) in order to share it.

But there is a rather large problem -- classes. Classes might have a __mutable buried in a derived object that the compiler isn't aware of. So that is a no-go.

Another possibility is to introduce new type qualifiers, like immutable-with-mutable or const-with-mutable, which are not shared, but I feel like the appetite for new qualifiers is pretty low, and the names...

I've come to the conclusion, in order to fix this situation, so __mutable really means mutable and shared is an orthogonal piece, you need to remove the implicit sharing of immutable. While it can make sense, the conflation of the two concepts causes impossible-to-fix issues. Not just mutable, things like thread-local garbage collection might be easier if you have to explicitly share things.

-Steve

I really don't think this makes sense.

Providing people with tool to work on multiple cores (and we are aggressively moving toward heterogeneous compute, so it's getting worse).

On the other hand, atomic are becoming cheaper and cheaper with each generation of pretty much every platforms. This is mostly due to the fact most machines now do regular loads/stores optimistically and speculate from there, just like they do for branch predictions. If it turns out there was contention then they rewind and revert back to do it in a more expensive fashion.

So that trade does not seems to make sense.

On Friday, 12 November 2021 at 12:31:03 UTC, Steven Schveighoffer wrote:

Just putting this here for reference (regarding implicitly shared immutable)

On 11/12/21 12:46 PM, deadalnix wrote:

shared(immutable) is fine for such a task. You only need to atomically load any __mutable pieces inside.

having immutable implicitly shared is stupid when it's obviously not. Like an immutable stack variable, why should I have to worry about sharability there? Should I even be able to share it with another thread, as the stack is easily destroyed?

Removing implicit sharing from immutable doesn't change what shared immutable means, or affect the performance of it, it just means you need to be explicit about sharing.

-Steve

On 11/12/21 1:12 PM, Andrei Alexandrescu wrote:

I'm not going to fight for this, I just wanted to bring it up. But I think it's pointless to try for reference counting of immutable data (the long RCSlice thread), when it's obviously not immutable data.

The only solution is to make it not mean the same as immutable does now (i.e. possibly shared). The fact that shared(immutable) would mean the same thing as immutable does now is a path forward, but I can understand if nobody wants to do that. I happen to think most cases people are not sharing their immutable data, just like they mostly aren't sharing thread-local data.

-Steve

On Friday, 12 November 2021 at 18:12:14 UTC, Andrei Alexandrescu wrote:

Just track whether an RC target needs atomic RC operations at compile time, using the template parameters of RC types. No changes to language semantics are necessary.

For example, reject attempts to assign an RCPtr!(immutable T) to an RCPtr!(const T), while allowing assignment to a RCPtr!(shared const T). Borrowed payloads can and should follow the normal D qualifier conversion rules.

Or, if more granularity is needed, use a separate template parameter:

struct RCPtr(T, bool sharedMeta = is(T == shared))

The very idea is strange. If RCSlice is mutable, how can it be immutable? Something doesn't add up.

On Friday, 12 November 2021 at 19:22:57 UTC, tsbockman wrote:

struct RCPtr(T, bool sharedMeta = is(T == shared))

This is essentially what Rust does--except instead of a template parameter, they have two separate generic types, Rc<T> and Arc<T>.