• simendsjo (10/10) Oct 23 2011 What does shared for functions mean? I thought it was supposed to
• Jonathan M Davis (8/20) Oct 23 2011 shared doesn't automatically synchronize anything. I believe that it mak...
• simendsjo (7/27) Oct 23 2011 Guess it's about time to buy TDPL.
• Jonathan M Davis (12/48) Oct 23 2011 Not necessarily. There are a number of attributes that I belive that it ...
• bearophile (4/5) Oct 23 2011 I agree. Such sloppiness is a very good source for problems, long term o...
• Marco Leise (5/11) Nov 08 2011 +1
• Jacob Carlborg (5/25) Oct 23 2011 Then there's the problem of TDPL and DMD being out of sync. Is shared
• Steven Schveighoffer (13/23) Oct 24 2011 Shared functions do not affect the function. All they do is affect the ...
• simendsjo (16/41) Oct 24 2011 So you cannot create a function to be called on both shared and unshared...
• Steven Schveighoffer (8/46) Oct 24 2011 No. There isn't a hybrid that works as well as const does. I suspect o...
• simendsjo (11/21) Oct 24 2011 Perhaps infrequent, but I just encountered a use-case:
• mta`chrono (3/11) Oct 26 2011 I would rather prefer "auto s1 = new shared(S);" because "shared s1 =

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
   }
}

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

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).

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

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

"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.

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

"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

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
}

"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

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..

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.