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

Reply via email to