www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Shared Classes

reply S S.com <shammah.chancellor gmail.com> writes:
 It seems to me that the way things are currently implemented that a 
class itself has to be specifically made to handle being shared.   That 
is to say, I cannot import some general library and do (new shared 
LibraryType()) if the class doesn't support all the proper shared 
methods.  In order for the class to properly implement the shared 
methods, it basically needs to be defined as such:

shared class Foo
{
	....
}

But now I still need to do shared Foo everywhere I use that class.  
This seems a bit off to me.


R/
Shammah
Nov 09 2013
next sibling parent reply "evilrat" <evilrat666 gmail.com> writes:
On Saturday, 9 November 2013 at 16:55:18 UTC, S S.com wrote:
 It seems to me that the way things are currently implemented 
 that a class itself has to be specifically made to handle being 
 shared.   That is to say, I cannot import some general library 
 and do (new shared LibraryType()) if the class doesn't support 
 all the proper shared methods.  In order for the class to 
 properly implement the shared methods, it basically needs to be 
 defined as such:

 shared class Foo
 {
 	....
 }

 But now I still need to do shared Foo everywhere I use that 
 class.  This seems a bit off to me.


 R/
 Shammah
actually you also need shared methods/memebers, shared works similar to const, so for example look at this: ------------------------------------------ import std.concurrency; import std.stdio; import core.thread; // notice no shared at class class A { shared void AddX() { x++; } shared int x; } // accepts shared instances only, so in this way you can't accidentally modify non-shared instances void worker(shared A inst) { inst.AddX(); writeln(inst.x); } void main() { shared A a = new shared A(); A b = new A(); // worker(b); // <-- fail! spawn(&worker, a); thread_joinAll(); } ----------------------------------------- so it is just storage specifier like const or immutable. and... ugh, sorry i'm too crappy on teaching people, but i hope you find this example somewhat helpful and someone else could give you more info on this.
Nov 09 2013
parent Shammah Chancellor <anonymous coward.com> writes:
On 2013-11-09 17:12:46 +0000, evilrat said:

 On Saturday, 9 November 2013 at 16:55:18 UTC, S S.com wrote:
 It seems to me that the way things are currently implemented that a 
 class itself has to be specifically made to handle being shared.   That 
 is to say, I cannot import some general library and do (new shared 
 LibraryType()) if the class doesn't support all the proper shared 
 methods.  In order for the class to properly implement the shared 
 methods, it basically needs to be defined as such:
 
 shared class Foo
 {
 	....
 }
 
 But now I still need to do shared Foo everywhere I use that class.  
 This seems a bit off to me.
 
 
 R/
 Shammah
actually you also need shared methods/memebers, shared works similar to const, so for example look at this: so it is just storage specifier like const or immutable. and... ugh, sorry i'm too crappy on teaching people, but i hope you find this example somewhat helpful and someone else could give you more info on this.
I understand how it works right now. My point is that it's dysfunctional. It's nearly impossible to make a class which can be declared as "shared" but also not shared. It's an all-or-nothing type proposition right now the way that implicit casting of shared works. Aside from that, if your class has any EXTERNAL dependencies, everything breaks: class Foo { Tid childFiber; .... <-- None of STD.concurrencies } auto x = new shared Foo(); <-- boom, none of std.concurrency takes shared(Tid). int[shared Foo] FooSet; <--- boom toHash not implemented for shared(Foo); class Foo { DataType initializationData; this( DataType input ) shared { initializationData = input; //Does not work as soon as Foo is declared is shared. } this(shared DataType input ) shared { initializationData = input; //Okay, but does not work if new is declared as as normally, without the shared keyword. } }
Nov 09 2013
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, November 09, 2013 11:55:19 S S.com wrote:
  It seems to me that the way things are currently implemented that a
 class itself has to be specifically made to handle being shared.   That
 is to say, I cannot import some general library and do (new shared
 LibraryType()) if the class doesn't support all the proper shared
 methods.  In order for the class to properly implement the shared
 methods, it basically needs to be defined as such:
 
 shared class Foo
 {
 	....
 }
 
 But now I still need to do shared Foo everywhere I use that class.
 This seems a bit off to me.
It's by design. The argument is that any type which is used across threads should be designed for it. I think that that's true to a point but that it's also frequently the case that it's desirable to use something as shared which is also normally used as thread-local, so on some level, I agree with you. It's something that Andrei is quite adamament about though. However, even if you don't believe that types which are supposed to be used as shared are fundamentally supposed to be designed to be used as shared and not in TLS, in order for shared to do its job, a variable needs to be typed as shared wherever it's used. Without that, the compiler can't make any guarantees about shared or TLS variables. It needs to be able to keep them separate - which it can't do if something isn't marked as shared everywhere that it's used as shared (including the this reference of member functions). So, even if you don't agree that types which are used as shared should be specially designed for it, you run into the problem that the type system pretty much requires marking member functions as shared in order to guarantee that shared objects are treated as shared. In theory, synchronized classes are supposed to strip the top level shared of their member variables inside their member functions, allowing you to use them as if they were TLS (since the type system then guarantees that they're only being used on that thread) and avoiding the need to make their member functions shared. However, synchronized classes have not yet been implemented (only synchronized functions), and that doesn't help with synchronized blocks or mutexes, and it doesn't help when you need more than just the top level of shared to be stripped off. So, I expect that in many cases, the way to use shared is going to be to protect it (with a mutex or synchronized block or whatever), cast away shared to operate on the object, make sure that no TLS references to it exist, and then unlock the mutex (or synchronized block or whatever). e.g. synchronized(myMutex) { auto n = cast(T)mySharedT; //do stuff to n like n.foo() or bar(n) //nothing should have a reference to n at this point } However some folks (Andrei in particular) don't like that paradigm, because it involves casting and is arguably bug-prone (certainly, you're losing any help from the type system in making sure that you don't end up with any non-shared references to shared data or accidentally end up using a shared object without having protected it with a lock first). I don't see any way around it though, not when even synchronized classes wouldn't be enough in many cases (because they only strip one layer of shared), and I think that it would often be overkill to create a synchronized class just to strip away shared on something (though it would have the advantage of giving you somewhere to put the mutex). But with synchronized classes not yet fully implemented, it's not like there's much choice at the moment. - Jonathan M Davis
Nov 09 2013