www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - What is shared functions?

reply simendsjo <simendsjo gmail.com> writes:
What does shared for functions mean? I thought it was supposed to 
automatically synchronize access, but this doesn't seem to be the case.

void f() shared {
// no synchronization
}

void f() {
   synchronized {
     // do stuff
   }
}
Oct 23 2011
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, October 23, 2011 14:32:34 simendsjo wrote:
 What does shared for functions mean? I thought it was supposed to
 automatically synchronize access, but this doesn't seem to be the case.
 
 void f() shared {
 // no synchronization
 }
 
 void f() {
    synchronized {
      // do stuff
    }
 }

shared doesn't automatically synchronize anything. I believe that it makes some guarantees about instruction ordering not being messed with by the compiler, but I'm not sure. I'd have to go look it up in TDPL though. Regardless, on a _function_, I don't think that shared does anything. D probably ignores it. It tends to do that with incorrect attributes. It _might_ do something though. I don't know. - Jonathan M Davis
Oct 23 2011
next sibling parent reply simendsjo <simendsjo gmail.com> writes:
On 23.10.2011 20:14, Jonathan M Davis wrote:
 On Sunday, October 23, 2011 14:32:34 simendsjo wrote:
 What does shared for functions mean? I thought it was supposed to
 automatically synchronize access, but this doesn't seem to be the case.

 void f() shared {
 // no synchronization
 }

 void f() {
     synchronized {
       // do stuff
     }
 }

shared doesn't automatically synchronize anything. I believe that it makes some guarantees about instruction ordering not being messed with by the compiler, but I'm not sure. I'd have to go look it up in TDPL though. Regardless, on a _function_, I don't think that shared does anything. D probably ignores it. It tends to do that with incorrect attributes. It _might_ do something though. I don't know. - Jonathan M Davis

Guess it's about time to buy TDPL. I remember D ignoring protection attributes before, but this is a bug now: private public class C {} t.d(1): redundant protection attribute So I guess shared has an effect on functions (or the missing error is a bug).
Oct 23 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

 my general take on it is that dmd should _never_ ignore attributes,

I agree. Such sloppiness is a very good source for problems, long term ones too, and it makes it harder to learn D. Bye, bearophile
Oct 23 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-10-23 20:14, Jonathan M Davis wrote:
 On Sunday, October 23, 2011 14:32:34 simendsjo wrote:
 What does shared for functions mean? I thought it was supposed to
 automatically synchronize access, but this doesn't seem to be the case.

 void f() shared {
 // no synchronization
 }

 void f() {
     synchronized {
       // do stuff
     }
 }

shared doesn't automatically synchronize anything. I believe that it makes some guarantees about instruction ordering not being messed with by the compiler, but I'm not sure. I'd have to go look it up in TDPL though. Regardless, on a _function_, I don't think that shared does anything. D probably ignores it. It tends to do that with incorrect attributes. It _might_ do something though. I don't know. - Jonathan M Davis

Then there's the problem of TDPL and DMD being out of sync. Is shared currently implemented like that? -- /Jacob Carlborg
Oct 23 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, October 23, 2011 20:22:01 simendsjo wrote:
 On 23.10.2011 20:14, Jonathan M Davis wrote:
 On Sunday, October 23, 2011 14:32:34 simendsjo wrote:
 What does shared for functions mean? I thought it was supposed to
 automatically synchronize access, but this doesn't seem to be the
 case.
 
 void f() shared {
 // no synchronization
 }
 
 void f() {
 
     synchronized {
     
       // do stuff
     
     }
 
 }

shared doesn't automatically synchronize anything. I believe that it makes some guarantees about instruction ordering not being messed with by the compiler, but I'm not sure. I'd have to go look it up in TDPL though. Regardless, on a _function_, I don't think that shared does anything. D probably ignores it. It tends to do that with incorrect attributes. It _might_ do something though. I don't know. - Jonathan M Davis

Guess it's about time to buy TDPL. I remember D ignoring protection attributes before, but this is a bug now: private public class C {} t.d(1): redundant protection attribute So I guess shared has an effect on functions (or the missing error is a bug).

Not necessarily. There are a number of attributes that I belive that it will continue to ignore in the interest of reducing errors with generated code. Just because it happens to complain in one particular case doesn't mean that it's been fixed in general. I believe that it's always been the case that dmd complains in some cases and not in others. It _is_ a bit annoying though. Maybe it would cause problems for generated code, by my general take on it is that dmd should _never_ ignore attributes, but that's not the way that it works unfortunately, So, it may be that shared does something here. It may be that it's ignored, and if it's ignored it may or may not be a bug that it compiles without error. - Jonathan M Davis
Oct 23 2011
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 23 Oct 2011 08:32:34 -0400, simendsjo <simendsjo gmail.com> wrote:

 What does shared for functions mean? I thought it was supposed to  
 automatically synchronize access, but this doesn't seem to be the case.

 void f() shared {
 // no synchronization
 }

 void f() {
    synchronized {
      // do stuff
    }
 }

Shared functions do not affect the function. All they do is affect the 'this' pointer. This: struct S { void f() shared {} } is roughly equivalent to this: struct S {} void f(shared ref Foo this){} -Steve
Oct 24 2011
parent reply simendsjo <simendsjo gmail.com> writes:
On 24.10.2011 17:23, Steven Schveighoffer wrote:
 On Sun, 23 Oct 2011 08:32:34 -0400, simendsjo <simendsjo gmail.com> wrote:

 What does shared for functions mean? I thought it was supposed to
 automatically synchronize access, but this doesn't seem to be the case.

 void f() shared {
 // no synchronization
 }

 void f() {
 synchronized {
 // do stuff
 }
 }

Shared functions do not affect the function. All they do is affect the 'this' pointer. This: struct S { void f() shared {} } is roughly equivalent to this: struct S {} void f(shared ref Foo this){} -Steve

So you cannot create a function to be called on both shared and unshared instances? For mutable/immutable there's const, but there is no "maybeShared". struct S { void onlyShared() shared {} void notShared() {} } void main() { shared s1 = cast(shared)new S(); s1.onlyShared(); // ok //s1.notShared(); // error: not callable using argument types () shared auto s2 = new S(); //s2.onlyShared(); // error: not callable using argument types () s2.notShared(); // ok }
Oct 24 2011
next sibling parent simendsjo <simendsjo gmail.com> writes:
On 24.10.2011 21:41, Steven Schveighoffer wrote:
 So you cannot create a function to be called on both shared and
 unshared instances? For mutable/immutable there's const, but there is
 no "maybeShared".

No. There isn't a hybrid that works as well as const does. I suspect one could be created, but it's very infrequent that you want to work with shared data in the same way you want to work with unshared data. With immutable vs. immutable, const incurs no penalty. But for shared vs. unshared, there is a very real penalty for obeying shared semantics.

Perhaps infrequent, but I just encountered a use-case: // Shared between all threads (created in module ctor) shared Context defaultContext = {...} // But each thread *could* create it's own context class Context { Socket create() {...} // so this could be called on both shared and unshared instances. The resulting socket should always be thread local } As I don't have any experience with shared, this might have implications I don't know about though..
Oct 24 2011
prev sibling parent mta`chrono <chrono mta-international.net> writes:
 void main() {
     shared s1 = cast(shared)new S();
     s1.onlyShared(); // ok
     //s1.notShared(); // error: not callable using argument types () shared
     auto s2 = new S();
     //s2.onlyShared(); // error: not callable using argument types ()
     s2.notShared(); // ok
 }

I would rather prefer "auto s1 = new shared(S);" because "shared s1 = new S();" seems to allocate a TLS variable which is then casted to shared which is actually non-TLS.
Oct 26 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 24 Oct 2011 12:01:07 -0400, simendsjo <simendsjo gmail.com> wrote:

 On 24.10.2011 17:23, Steven Schveighoffer wrote:
 On Sun, 23 Oct 2011 08:32:34 -0400, simendsjo <simendsjo gmail.com>  
 wrote:

 What does shared for functions mean? I thought it was supposed to
 automatically synchronize access, but this doesn't seem to be the case.

 void f() shared {
 // no synchronization
 }

 void f() {
 synchronized {
 // do stuff
 }
 }

Shared functions do not affect the function. All they do is affect the 'this' pointer. This: struct S { void f() shared {} } is roughly equivalent to this: struct S {} void f(shared ref Foo this){} -Steve

So you cannot create a function to be called on both shared and unshared instances? For mutable/immutable there's const, but there is no "maybeShared".

No. There isn't a hybrid that works as well as const does. I suspect one could be created, but it's very infrequent that you want to work with shared data in the same way you want to work with unshared data. With immutable vs. immutable, const incurs no penalty. But for shared vs. unshared, there is a very real penalty for obeying shared semantics. -Steve
Oct 24 2011
prev sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 23.10.2011, 21:51 Uhr, schrieb bearophile <bearophileHUGS lycos.com>:

 Jonathan M Davis:

 my general take on it is that dmd should _never_ ignore attributes,

I agree. Such sloppiness is a very good source for problems, long term ones too, and it makes it harder to learn D. Bye, bearophile

+1 For example I still wonder what final does to private methods. It makes me wonder if they are virtual and I should really add this keyword to be on the safe side.
Nov 08 2011