The "no gc" crowd

[Jacob Carlborg]

On 2013-10-10 09:24, Jonathan M Davis wrote:

> Pretty much nothing accepts shared. At best, templated functions accept
> shared. Certainly, shared doesn't work at all with classes and structs unless
> the type is specifically intended to be used as shared, because you have to
> mark all of its member functions shared to be able to call them. And if you
> want to use that class or struct as both shared and unshared, you have to
> duplicate all of its member functions.
>
> That being the case, the only way in general to use a shared object is to
> protect it with a lock, cast it to thread-local (so that it can actually use
> its member functions or be passed to other functions to be used), and then use
> it. e.g.
>
> synchronized
> {
>       auto tl = cast(T)mySharedT;
>       auto result = tl.foo();
>       auto result2 = bar(tl);
> }
>
> Obviously, you then have to make sure that there are no thread-local
> references to the shared object when the lock is released, but without casting
> away shared like that, you can't do much of anything with it. So, similar to
> when you cast away const, it's up to you to guarantee that the code doesn't
> violate the type system's guarantees - i.e. that a thread-local variable is
> not accessed by multiple threads. So, you use a lock of some kind to protect
> the shared variable while it's treated as a thread-local variable in order to
> ensure that that guarantee holds. Like with casting away const or with
> @trusted, there's obviously risk in doing this, but there's really no other
> way to use shared at this point - certainly not without it being incredibly
> invasive to your code and forcing code duplication.

Sounds like we need a way to tell that a parameter is thread local but 
not allowed to escape a reference to it.

Object foo;

void bar (shared_tls Object o)
{
     foo = o; // Compile error, cannot escape a "shared" thread local
}

void main ()
{
     auto o = new shared(Object);
     synchronized { bar(o); }
}

Both "shared" can thread local be passed to "shared_tls". If "shared" is 
passed it assumes to be synchronized during the call to "bar".

This will still have the problem of annotating all code with this 
attribute. Or this needs to be default, which would cause a lot of code 
breakage.

-- 
/Jacob Carlborg