A few thoughts on std.allocator

[Jakob Ovrum via Digitalmars-d]

On Wednesday, 13 May 2015 at 17:49:38 UTC, Steven Schveighoffer 
wrote:
> OK, then consider that this:
>
> void main()
> {
>    string x;
>    x ~= "hello";
>    x ~= " world";
> }
>
> would require locking. That's unacceptable. Nobody would append 
> with strings if this all required locking for no reason. The 
> runtime currently does NOT lock for this case, it considers 
> immutable and const to be thread-local.

Well, it's necessary because the design of druntime arrays is 
incompatible with D2's type system. Without locking, 
multi-threaded applications that use dynamic array operations 
could easily contain some particularly hard to track concurrency 
bugs.

Simply not doing the locking and hoping that everything is fine 
doesn't sound like a good plan (which I think we agree on, since 
shared(immutable(T)) would solve it).

> No, I think the answer is simpler. Introduce shared(immutable), 
> and then we can distinguish between immutable data that is 
> shared and data that is not shared. It also makes implementing 
> local heaps easier. Shared really is orthogonal to mutability.

Basically, shared(immutable(T)) would only be useful to 
allocators, including arrays because they may need to allocate 
when growing. I don't think it would be useful beyond that; the 
sharedness of immutable data is probably not interesting to any 
other kind of code.

It would make immutable considerably harder to use than it is 
today. shared(immutable(T)) would be implicitly convertible to 
shared(const(T)), but not const(T), which precludes the vast 
majority of mutation-agnostic D code out there today (I have 
never seen shared(const(T)) used in the wild). We would no longer 
be able to do even the simplest things, like passing a path 
string to another thread and use std.file.read on it.

> Here's something even weirder: If you append to y 
> (const(int)[]) as a reference to x (immutable(int)[]), then 
> part of the array is immutable and shareable, and the part that 
> was appended is const and not shareable.

This should be the case for user-defined containers as well as 
long as the element type doesn't have mutable indirection. 
Appending on slices seems to handle this correctly as well, 
rejecting attempts to append a const(T)[] to an immutable(T)[] 
when T has mutable indirection.

> This should work:
>
> void main()
> {
>    auto s = new S;
>    passToOtherThread(&s.b);
> }
>
> Which makes s.a unshared, and s.b shared. But the memory block 
> needs to be shareable.

That is an interesting example. Plain shared has the same problem:

struct S {
     int a;
     shared int b;
}

void main() {
     import std.concurrency;

     auto tid = spawn(() {});
     auto s = new S;
     tid.send(&s.b);
}

Types that contain shared anywhere within the type would have to 
be allocated from a global allocator, and with the current state 
of immutable, the same would have to be done for types that 
contain immutable anywhere within it. Note that it's only the 
case for head-shared/head-immutable; types like immutable(T)[] or 
shared(T)* don't count.