On 03/12/2010 18:23, Steven Schveighoffer wrote:
On Fri, 03 Dec 2010 11:23:48 -0500, Bruno Medeiros
<brunodomedeiros+s...@com.gmail> wrote:
On 03/12/2010 13:22, Steven Schveighoffer wrote:
> I actually re-read the code and realized that it should work without
any
> changes (sans the issue you bring up below with implicit sharing of
> immutable).
>
You mean if you wanted to pass a mutable object back and forth?
No it wouldn't, if I understood you correctly. It would merely
compile, but not work (in the general case). So you would create an
object, cast it to shared (which means access would now need to be
synchronized), and pass it to another thread, right? However when you
pass to another thread the TLS part of the object state is lost (aka
the _mutable part). That might be valid for cached data that can be
recalculated (like the determinant), but it would not be valid for
other kinds of mutable data that the object would require and should
not be cleared (like the parent Widget in the other example you gave).
the mutable member is not marked as shared. It cannot be accessed on a
shared instance. I guess it should be explicitly noted that a logical
const notation (such as 'mutable') would not affect shared status, only
const status. shared does not implicitly cast to unshared or unshared
const.
-Steve
Oh, I see what you mean. I thought something like this (or similar) worked:
shared X foo = new shared(X);
synchronized(foo) {
foo.mutable(2);
}
I was thinking that the synchronized block would remove the shared type
qualifier from foo inside the block.
--
Bruno Medeiros - Software Engineer
