Michel Fortin wrote:
On 2010-08-04 21:55:33 -0400, Jonathan M Davis <jmdavisp...@gmail.com>
said:
I would have thought that sharing pretty much _any_ type more complex
than a
primitive type without it being synchronized would be a bad idea. And
since the
standard containers obviously aren't going to be synchronized, I would
expect
you to have to wrap them in a class or struct which is synchronized.
You're exactly right Jonathan. The problem is that 'synchronized' only
protects what's directly inside the class and doesn't protect anything
beyond an indirection. The container and its reference counter is beyond
an indirection, so it is not protected by 'synchronized' and is thus
'shared' according to the type system.
So that's what the type system tells you. You can cast your way around
that undesired 'shared', and it's the only way to use a container in a
synchronized class. I think that's the reason dsimcha wants the
documentation to be clearer. Because using a container inside a
synchronized class is probably going to be a common thing, what you
should and should not do with the container should be documented for
when you cast your way around the type system.
Personally, I'd say that not being able to use a container inside a
synchronized class without subverting the type system looks like a
failure of the type system.
How about an insufficiency of the container library?
Andrei
