digitalmars.D - Shared Delegates
- Andrew Wiley (28/28) Oct 17 2011 Okay, I realize there have been some discussions about this, but I have ...
- Michel Fortin (9/42) Oct 17 2011 I think what's wrong is that a shared delegate should implicitly
- Benjamin Thaut (8/52) Oct 17 2011 I reported this exact issue already a few months ago and simply didn't
- Andrew Wiley (3/58) Oct 17 2011 Ah, I was looking through the bug reports and didn't see this exact bug....
- Benjamin Thaut (6/69) Oct 17 2011 I didn't file it yet, so file it. I do however think that currently
- Andrew Wiley (16/102) Oct 17 2011 This much is clearly a bug, and Michel's explanation of how shared deleg...
- Andrew Wiley (3/96) Oct 18 2011 Filed as http://d.puremagic.com/issues/show_bug.cgi?id=6823
- Andrew Wiley (19/62) Oct 19 2011 Actually, I've been thinking about this some more, and I think that the
- Michel Fortin (11/74) Oct 19 2011 Is it? Whether the argument was shared or not, the thread in which the
- Andrew Wiley (8/92) Oct 19 2011 The problem is that what's behind the context pointer is also shared. If
- Michel Fortin (14/116) Oct 19 2011 I think I see what you mean, but you're probably missing one little deta...
- Robert Jacques (9/10) Oct 19 2011 [snip]
- Andrew Wiley (6/22) Oct 19 2011 Ah, I see, so I can pass unshared data or references to unshared data in...
Okay, I realize there have been some discussions about this, but I have a
few questions about shared delegates because right now they are definitely
broken, but I'm not sure how.
Take this code example:
synchronized class Thing {
void doSomeWork(void delegate() work) {
work();
}
void work() {}
}
void main() {
auto th = new Thing();
th.doSomeWork(&th.work);
}
This doesn't compile because the type of "&th.work" is "void delegate()
shared", which cannot be cast implicitly to "void delegate()".
My first question would be whether that type is correct. It's true that the
data pointer of the delegate points to a shared object, but given that the
function locks it, does that really matter in this case? I guess I'm just
not clear on the exact meaning of "shared" in general, but it seems like
whether the data is shared or not is irrelevant when the delegate points to
a public member of a synchronized class. If it was a delegate pointing to a
private/protected member (which should be illegal in this case), that would
not be true.
If that type is correct, the problem is that "void delegate() shared"
doesn't parse as a type (there is a workaround because you can create
variables of this type through alias and typeof).
What, exactly, is wrong here?
Oct 17 2011
On 2011-10-17 20:33:59 +0000, Andrew Wiley <wiley.andrew.j gmail.com> said:
Okay, I realize there have been some discussions about this, but I have a
few questions about shared delegates because right now they are definitely
broken, but I'm not sure how.
Take this code example:
synchronized class Thing {
void doSomeWork(void delegate() work) {
work();
}
void work() {}
}
void main() {
auto th = new Thing();
th.doSomeWork(&th.work);
}
This doesn't compile because the type of "&th.work" is "void delegate()
shared", which cannot be cast implicitly to "void delegate()".
My first question would be whether that type is correct. It's true that the
data pointer of the delegate points to a shared object, but given that the
function locks it, does that really matter in this case? I guess I'm just
not clear on the exact meaning of "shared" in general, but it seems like
whether the data is shared or not is irrelevant when the delegate points to
a public member of a synchronized class. If it was a delegate pointing to a
private/protected member (which should be illegal in this case), that would
not be true.
If that type is correct, the problem is that "void delegate() shared"
doesn't parse as a type (there is a workaround because you can create
variables of this type through alias and typeof).
What, exactly, is wrong here?
I think what's wrong is that a shared delegate should implicitly
convert to a non-shared one. The delegate is shared since it can be
called safely from any thread, and making it non-shared only prevent
you from propagating it to more thread so it's not harmful in any way.
--
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Oct 17 2011
Am 17.10.2011 22:43, schrieb Michel Fortin:On 2011-10-17 20:33:59 +0000, Andrew Wiley <wiley.andrew.j gmail.com> said:I reported this exact issue already a few months ago and simply didn't get any comment on it. If you really try to use shared to are going to hit more such problems. See the shared section of my blogpost: http://3d.benjamin-thaut.de/?p=18 -- Kind Regards Benjamin ThautOkay, I realize there have been some discussions about this, but I have a few questions about shared delegates because right now they are definitely broken, but I'm not sure how. Take this code example: synchronized class Thing { void doSomeWork(void delegate() work) { work(); } void work() {} } void main() { auto th = new Thing(); th.doSomeWork(&th.work); } This doesn't compile because the type of "&th.work" is "void delegate() shared", which cannot be cast implicitly to "void delegate()". My first question would be whether that type is correct. It's true that the data pointer of the delegate points to a shared object, but given that the function locks it, does that really matter in this case? I guess I'm just not clear on the exact meaning of "shared" in general, but it seems like whether the data is shared or not is irrelevant when the delegate points to a public member of a synchronized class. If it was a delegate pointing to a private/protected member (which should be illegal in this case), that would not be true. If that type is correct, the problem is that "void delegate() shared" doesn't parse as a type (there is a workaround because you can create variables of this type through alias and typeof). What, exactly, is wrong here?I think what's wrong is that a shared delegate should implicitly convert to a non-shared one. The delegate is shared since it can be called safely from any thread, and making it non-shared only prevent you from propagating it to more thread so it's not harmful in any way.
Oct 17 2011
On Tue, Oct 18, 2011 at 12:53 AM, Benjamin Thaut <code benjamin-thaut.de>wrote:Am 17.10.2011 22:43, schrieb Michel Fortin: On 2011-10-17 20:33:59 +0000, Andrew Wiley <wiley.andrew.j gmail.com>Ah, I was looking through the bug reports and didn't see this exact bug. Did I just fail at searching, or should I file it?said:I reported this exact issue already a few months ago and simply didn't get any comment on it. If you really try to use shared to are going to hit more such problems. See the shared section of my blogpost: http://3d.benjamin-thaut.de/?**p=18<http://3d.benjamin-thaut.de/?p=18>Okay, I realize there have been some discussions about this, but I have a few questions about shared delegates because right now they are definitely broken, but I'm not sure how. Take this code example: synchronized class Thing { void doSomeWork(void delegate() work) { work(); } void work() {} } void main() { auto th = new Thing(); th.doSomeWork(&th.work); } This doesn't compile because the type of "&th.work" is "void delegate() shared", which cannot be cast implicitly to "void delegate()". My first question would be whether that type is correct. It's true that the data pointer of the delegate points to a shared object, but given that the function locks it, does that really matter in this case? I guess I'm just not clear on the exact meaning of "shared" in general, but it seems like whether the data is shared or not is irrelevant when the delegate points to a public member of a synchronized class. If it was a delegate pointing to a private/protected member (which should be illegal in this case), that would not be true. If that type is correct, the problem is that "void delegate() shared" doesn't parse as a type (there is a workaround because you can create variables of this type through alias and typeof). What, exactly, is wrong here?I think what's wrong is that a shared delegate should implicitly convert to a non-shared one. The delegate is shared since it can be called safely from any thread, and making it non-shared only prevent you from propagating it to more thread so it's not harmful in any way.
Oct 17 2011
Am 18.10.2011 08:03, schrieb Andrew Wiley:
On Tue, Oct 18, 2011 at 12:53 AM, Benjamin Thaut <code benjamin-thaut.de
<mailto:code benjamin-thaut.de>> wrote:
Am 17.10.2011 22:43, schrieb Michel Fortin:
On 2011-10-17 20:33:59 +0000, Andrew Wiley
<wiley.andrew.j gmail.com <mailto:wiley.andrew.j gmail.com>> said:
Okay, I realize there have been some discussions about this,
but I have a
few questions about shared delegates because right now they are
definitely
broken, but I'm not sure how.
Take this code example:
synchronized class Thing {
void doSomeWork(void delegate() work) {
work();
}
void work() {}
}
void main() {
auto th = new Thing();
th.doSomeWork(&th.work);
}
This doesn't compile because the type of "&th.work" is "void
delegate()
shared", which cannot be cast implicitly to "void delegate()".
My first question would be whether that type is correct.
It's true
that the
data pointer of the delegate points to a shared object, but
given that
the
function locks it, does that really matter in this case? I
guess I'm just
not clear on the exact meaning of "shared" in general, but
it seems like
whether the data is shared or not is irrelevant when the
delegate
points to
a public member of a synchronized class. If it was a
delegate pointing
to a
private/protected member (which should be illegal in this
case), that
would
not be true.
If that type is correct, the problem is that "void
delegate() shared"
doesn't parse as a type (there is a workaround because you
can create
variables of this type through alias and typeof).
What, exactly, is wrong here?
I think what's wrong is that a shared delegate should implicitly
convert
to a non-shared one. The delegate is shared since it can be called
safely from any thread, and making it non-shared only prevent
you from
propagating it to more thread so it's not harmful in any way.
I reported this exact issue already a few months ago and simply
didn't get any comment on it. If you really try to use shared to are
going to hit more such problems.
See the shared section of my blogpost:
http://3d.benjamin-thaut.de/?__p=18 <http://3d.benjamin-thaut.de/?p=18>
Ah, I was looking through the bug reports and didn't see this exact bug.
Did I just fail at searching, or should I file it?
I didn't file it yet, so file it. I do however think that currently
there is no intention in changing the way shared works.
--
Kind Regards
Benjamin Thaut
Oct 17 2011
Andrew Wiley <wiley.andrew.j gmail.com> On Tue, Oct 18, 2011 at 1:11 AM, Benjamin Thaut <code benjamin-thaut.de>wrote:Am 18.10.2011 08:03, schrieb Andrew Wiley:This much is clearly a bug, and Michel's explanation of how shared delegates should work makes a lot of sense. As for the synchronized classes that synchronize access to not-really-shared members, well, I don't think that's changing. The problem is that the compiler can't *guarantee* that the reference you hold is the only reference. TDPL has a discussion of why an "A owns B, so A's lock should be good enough for B" wasn't implemented. As for the overloading on shared, the idea there was that you should really either be multithreaded or not - trying to implement both shared and non-shared versions of code is generally a bad idea and quite bug prone. If it *might* be shared, just synchronize it. Premature optimization is the root of quite a bit of evil, and trying to make some things thread safe and some things not is walking a tightrope without any sense of balance - you won't know when you fall, you'll just see the corruption when you hit the floor.On Tue, Oct 18, 2011 at 12:53 AM, Benjamin Thaut <code benjamin-thaut.de <mailto:code benjamin-thaut.de**>> wrote: Am 17.10.2011 22:43, schrieb Michel Fortin: On 2011-10-17 20:33:59 +0000, Andrew Wiley <wiley.andrew.j gmail.com <mailto:wiley.andrew.j gmail.**com<wiley.andrew.j gmail.com>>> said: Okay, I realize there have been some discussions about this, but I have a few questions about shared delegates because right now they are definitely broken, but I'm not sure how. Take this code example: synchronized class Thing { void doSomeWork(void delegate() work) { work(); } void work() {} } void main() { auto th = new Thing(); th.doSomeWork(&th.work); } This doesn't compile because the type of "&th.work" is "void delegate() shared", which cannot be cast implicitly to "void delegate()". My first question would be whether that type is correct. It's true that the data pointer of the delegate points to a shared object, but given that the function locks it, does that really matter in this case? I guess I'm just not clear on the exact meaning of "shared" in general, but it seems like whether the data is shared or not is irrelevant when the delegate points to a public member of a synchronized class. If it was a delegate pointing to a private/protected member (which should be illegal in this case), that would not be true. If that type is correct, the problem is that "void delegate() shared" doesn't parse as a type (there is a workaround because you can create variables of this type through alias and typeof). What, exactly, is wrong here? I think what's wrong is that a shared delegate should implicitly convert to a non-shared one. The delegate is shared since it can be called safely from any thread, and making it non-shared only prevent you from propagating it to more thread so it's not harmful in any way. I reported this exact issue already a few months ago and simply didn't get any comment on it. If you really try to use shared to are going to hit more such problems. See the shared section of my blogpost: http://3d.benjamin-thaut.de/?_**_p=18<http://3d.benjamin-thaut.de/?__p=18>< http://3d.benjamin-thaut.de/?**p=18 <http://3d.benjamin-thaut.de/?p=18>> Ah, I was looking through the bug reports and didn't see this exact bug. Did I just fail at searching, or should I file it?I didn't file it yet, so file it. I do however think that currently there is no intention in changing the way shared works.
Oct 17 2011
On Tue, Oct 18, 2011 at 1:48 AM, Andrew Wiley <wiley.andrew.j gmail.com>wrote:On Tue, Oct 18, 2011 at 1:11 AM, Benjamin Thaut <code benjamin-thaut.de>wrote:Filed as http://d.puremagic.com/issues/show_bug.cgi?id=6823 For now, I can just cast things at the call site.Am 18.10.2011 08:03, schrieb Andrew Wiley:This much is clearly a bug, and Michel's explanation of how shared delegates should work makes a lot of sense.On Tue, Oct 18, 2011 at 12:53 AM, Benjamin Thaut <code benjamin-thaut.de <mailto:code benjamin-thaut.de**>> wrote: Am 17.10.2011 22:43, schrieb Michel Fortin: On 2011-10-17 20:33:59 +0000, Andrew Wiley <wiley.andrew.j gmail.com <mailto:wiley.andrew.j gmail.**com<wiley.andrew.j gmail.com>>> said: Okay, I realize there have been some discussions about this, but I have a few questions about shared delegates because right now they are definitely broken, but I'm not sure how. Take this code example: synchronized class Thing { void doSomeWork(void delegate() work) { work(); } void work() {} } void main() { auto th = new Thing(); th.doSomeWork(&th.work); } This doesn't compile because the type of "&th.work" is "void delegate() shared", which cannot be cast implicitly to "void delegate()". My first question would be whether that type is correct. It's true that the data pointer of the delegate points to a shared object, but given that the function locks it, does that really matter in this case? I guess I'm just not clear on the exact meaning of "shared" in general, but it seems like whether the data is shared or not is irrelevant when the delegate points to a public member of a synchronized class. If it was a delegate pointing to a private/protected member (which should be illegal in this case), that would not be true. If that type is correct, the problem is that "void delegate() shared" doesn't parse as a type (there is a workaround because you can create variables of this type through alias and typeof). What, exactly, is wrong here? I think what's wrong is that a shared delegate should implicitly convert to a non-shared one. The delegate is shared since it can be called safely from any thread, and making it non-shared only prevent you from propagating it to more thread so it's not harmful in any way. I reported this exact issue already a few months ago and simply didn't get any comment on it. If you really try to use shared to are going to hit more such problems. See the shared section of my blogpost: http://3d.benjamin-thaut.de/?_**_p=18<http://3d.benjamin-thaut.de/?__p=18>< http://3d.benjamin-thaut.de/?**p=18 <http://3d.benjamin-thaut.de/?p=18>> Ah, I was looking through the bug reports and didn't see this exact bug. Did I just fail at searching, or should I file it?I didn't file it yet, so file it. I do however think that currently there is no intention in changing the way shared works.
Oct 18 2011
On Mon, Oct 17, 2011 at 3:43 PM, Michel Fortin <michel.fortin michelf.com>wrote:On 2011-10-17 20:33:59 +0000, Andrew Wiley <wiley.andrew.j gmail.com> said:Actually, I've been thinking about this some more, and I think that the delegate should only implicitly convert if the argument types are safe to share across threads as well. If I had a class that looked like this: synchronized class Thing2 { void doSomeWork(int i) {} void doSomeOtherWork(Thing2 t) {} void work() {} } The actual argument type in doSomeOtherWork is required to be shared(Thing2) (which isn't a problem here because Thing2 is a synchronized class, but you see the point). These same rules should apply to shared delegates. I'm not sure exactly how this works for value types because they're always safe to pass as arguments yet shared(int) clearly isn't the same as int, but the rules will be the same for delegates as for member functions. With that in mind, I'm not sure exactly how the implicit conversions should work, but the argument types should always be properly share-able.Okay, I realize there have been some discussions about this, but I have a few questions about shared delegates because right now they are definitely broken, but I'm not sure how. Take this code example: synchronized class Thing { void doSomeWork(void delegate() work) { work(); } void work() {} } void main() { auto th = new Thing(); th.doSomeWork(&th.work); } This doesn't compile because the type of "&th.work" is "void delegate() shared", which cannot be cast implicitly to "void delegate()". My first question would be whether that type is correct. It's true that the data pointer of the delegate points to a shared object, but given that the function locks it, does that really matter in this case? I guess I'm just not clear on the exact meaning of "shared" in general, but it seems like whether the data is shared or not is irrelevant when the delegate points to a public member of a synchronized class. If it was a delegate pointing to a private/protected member (which should be illegal in this case), that would not be true. If that type is correct, the problem is that "void delegate() shared" doesn't parse as a type (there is a workaround because you can create variables of this type through alias and typeof). What, exactly, is wrong here?I think what's wrong is that a shared delegate should implicitly convert to a non-shared one. The delegate is shared since it can be called safely from any thread, and making it non-shared only prevent you from propagating it to more thread so it's not harmful in any way.
Oct 19 2011
On 2011-10-19 20:36:37 +0000, Andrew Wiley <wiley.andrew.j gmail.com> said:On Mon, Oct 17, 2011 at 3:43 PM, Michel Fortin <michel.fortin michelf.com>wrote:I disagree.On 2011-10-17 20:33:59 +0000, Andrew Wiley <wiley.andrew.j gmail.com> said:Actually, I've been thinking about this some more, and I think that the delegate should only implicitly convert if the argument types are safe to share across threads as well.Okay, I realize there have been some discussions about this, but I have a few questions about shared delegates because right now they are definitely broken, but I'm not sure how. Take this code example: synchronized class Thing { void doSomeWork(void delegate() work) { work(); } void work() {} } void main() { auto th = new Thing(); th.doSomeWork(&th.work); } This doesn't compile because the type of "&th.work" is "void delegate() shared", which cannot be cast implicitly to "void delegate()". My first question would be whether that type is correct. It's true that the data pointer of the delegate points to a shared object, but given that the function locks it, does that really matter in this case? I guess I'm just not clear on the exact meaning of "shared" in general, but it seems like whether the data is shared or not is irrelevant when the delegate points to a public member of a synchronized class. If it was a delegate pointing to a private/protected member (which should be illegal in this case), that would not be true. If that type is correct, the problem is that "void delegate() shared" doesn't parse as a type (there is a workaround because you can create variables of this type through alias and typeof). What, exactly, is wrong here?I think what's wrong is that a shared delegate should implicitly convert to a non-shared one. The delegate is shared since it can be called safely from any thread, and making it non-shared only prevent you from propagating it to more thread so it's not harmful in any way.If I had a class that looked like this: synchronized class Thing2 { void doSomeWork(int i) {} void doSomeOtherWork(Thing2 t) {} void work() {} } The actual argument type in doSomeOtherWork is required to be shared(Thing2) (which isn't a problem here because Thing2 is a synchronized class, but you see the point).Is it? Whether the argument was shared or not, the thread in which the function code runs can only access thread-local data from that thread, including the arguments and global variables. It won't be able to send references to non-shared data to other threads just because its context pointer is shared (or synchronized). -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Oct 19 2011
On Wed, Oct 19, 2011 at 4:11 PM, Michel Fortin <michel.fortin michelf.com>wrote:On 2011-10-19 20:36:37 +0000, Andrew Wiley <wiley.andrew.j gmail.com> said:The problem is that what's behind the context pointer is also shared. If this delegate is just a closure, that doesn't matter, since the context is basically immutable. The problem I see is when the delegate is actually a member function that stores data in an object. If it was passed a reference to non-shared data, it could store that reference in a shared object, breaking transitive shared.On Mon, Oct 17, 2011 at 3:43 PM, Michel Fortin <michel.fortin michelf.comI disagree. If I had a class that looked like this:**wrote:On 2011-10-17 20:33:59 +0000, Andrew Wiley <wiley.andrew.j gmail.com>said: Okay, I realize there have been some discussions about this, but I haveActually, I've been thinking about this some more, and I think that the delegate should only implicitly convert if the argument types are safe to share across threads as well.a few questions about shared delegates because right now they are definitely broken, but I'm not sure how. Take this code example: synchronized class Thing { void doSomeWork(void delegate() work) { work(); } void work() {} } void main() { auto th = new Thing(); th.doSomeWork(&th.work); } This doesn't compile because the type of "&th.work" is "void delegate() shared", which cannot be cast implicitly to "void delegate()". My first question would be whether that type is correct. It's true that the data pointer of the delegate points to a shared object, but given that the function locks it, does that really matter in this case? I guess I'm just not clear on the exact meaning of "shared" in general, but it seems like whether the data is shared or not is irrelevant when the delegate points to a public member of a synchronized class. If it was a delegate pointing to a private/protected member (which should be illegal in this case), that would not be true. If that type is correct, the problem is that "void delegate() shared" doesn't parse as a type (there is a workaround because you can create variables of this type through alias and typeof). What, exactly, is wrong here?I think what's wrong is that a shared delegate should implicitly convert to a non-shared one. The delegate is shared since it can be called safely from any thread, and making it non-shared only prevent you from propagating it to more thread so it's not harmful in any way.synchronized class Thing2 { void doSomeWork(int i) {} void doSomeOtherWork(Thing2 t) {} void work() {} } The actual argument type in doSomeOtherWork is required to be shared(Thing2) (which isn't a problem here because Thing2 is a synchronized class, but you see the point).Is it? Whether the argument was shared or not, the thread in which the function code runs can only access thread-local data from that thread, including the arguments and global variables. It won't be able to send references to non-shared data to other threads just because its context pointer is shared (or synchronized).
Oct 19 2011
On 2011-10-19 21:53:12 +0000, Andrew Wiley <wiley.andrew.j gmail.com> said:On Wed, Oct 19, 2011 at 4:11 PM, Michel Fortin <michel.fortin michelf.com>wrote:I think I see what you mean, but you're probably missing one little detail… Implicitly casting the delegate to non-shared won't change what compiled code the delegate points to. The compiled code of the delegate was compiled with a shared 'this' pointer in mind. Since the attributes of the 'this' pointer is engraved in the compiled code when the function was compiled, changing the attributes of the delegate (a mere pointer to that code) won't change how the function treats 'this'. And since the 'this' pointer is shared inside the function you can't assign anything to it that isn't shared. -- Michel Fortin michel.fortin michelf.com http://michelf.com/On 2011-10-19 20:36:37 +0000, Andrew Wiley <wiley.andrew.j gmail.com> said:The problem is that what's behind the context pointer is also shared. If this delegate is just a closure, that doesn't matter, since the context is basically immutable. The problem I see is when the delegate is actually a member function that stores data in an object. If it was passed a reference to non-shared data, it could store that reference in a shared object, breaking transitive shared.On Mon, Oct 17, 2011 at 3:43 PM, Michel Fortin <michel.fortin michelf.comI disagree. If I had a class that looked like this:**wrote:On 2011-10-17 20:33:59 +0000, Andrew Wiley <wiley.andrew.j gmail.com>said: Okay, I realize there have been some discussions about this, but I haveActually, I've been thinking about this some more, and I think that the delegate should only implicitly convert if the argument types are safe to share across threads as well.a few questions about shared delegates because right now they are definitely broken, but I'm not sure how. Take this code example: synchronized class Thing { void doSomeWork(void delegate() work) { work(); } void work() {} } void main() { auto th = new Thing(); th.doSomeWork(&th.work); } This doesn't compile because the type of "&th.work" is "void delegate() shared", which cannot be cast implicitly to "void delegate()". My first question would be whether that type is correct. It's true that the data pointer of the delegate points to a shared object, but given that the function locks it, does that really matter in this case? I guess I'm just not clear on the exact meaning of "shared" in general, but it seems like whether the data is shared or not is irrelevant when the delegate points to a public member of a synchronized class. If it was a delegate pointing to a private/protected member (which should be illegal in this case), that would not be true. If that type is correct, the problem is that "void delegate() shared" doesn't parse as a type (there is a workaround because you can create variables of this type through alias and typeof). What, exactly, is wrong here?I think what's wrong is that a shared delegate should implicitly convert to a non-shared one. The delegate is shared since it can be called safely from any thread, and making it non-shared only prevent you from propagating it to more thread so it's not harmful in any way.synchronized class Thing2 { void doSomeWork(int i) {} void doSomeOtherWork(Thing2 t) {} void work() {} } The actual argument type in doSomeOtherWork is required to be shared(Thing2) (which isn't a problem here because Thing2 is a synchronized class, but you see the point).Is it? Whether the argument was shared or not, the thread in which the function code runs can only access thread-local data from that thread, including the arguments and global variables. It won't be able to send references to non-shared data to other threads just because its context pointer is shared (or synchronized).
Oct 19 2011
On Wed, 19 Oct 2011 20:51:25 -0400, Michel Fortin <michel.fortin michelf.com> wrote:On 2011-10-19 21:53:12 +0000, Andrew Wiley <wiley.andrew.j gmail.com> said:[snip] Also, I how shared works is being misunderstood. Making a class synchronized should limit all member functions and field to being shared or immutable, but it doesn't place any limits on the argument to the member functions. So in the below: synchronized class Thing2 { void doSomeWork(int i) {} void doSomeOtherWork(Thing2 t) {} void work() {} } i is of type int, not shared(int).
Oct 19 2011
On Wed, Oct 19, 2011 at 9:38 PM, Robert Jacques <sandford jhu.edu> wrote:On Wed, 19 Oct 2011 20:51:25 -0400, Michel Fortin < michel.fortin michelf.com> wrote:Ah, I see, so I can pass unshared data or references to unshared data into member functions, and the type system keeps me from saving them to member fields because member fields will be flagged as shared, but the arguments need not be. That makes a lot more sense. Sorry for the noise.On 2011-10-19 21:53:12 +0000, Andrew Wiley <wiley.andrew.j gmail.com> said:[snip] Also, I how shared works is being misunderstood. Making a class synchronized should limit all member functions and field to being shared or immutable, but it doesn't place any limits on the argument to the member functions. So in the below: synchronized class Thing2 { void doSomeWork(int i) {} void doSomeOtherWork(Thing2 t) {} void work() {} } i is of type int, not shared(int).
Oct 19 2011