Matt Wrote: > Jason House Wrote: > > > Matt Wrote: > > > Is this about right? > > > > I don't think so. What happens when the lock is released? Any residual use > > of the cast data is going to be incorrect (lacks a lock). What that means > > is that the cast is unsafe even when the data is locked! Casting is a back > > door that should be used with extreme care. > > You're right - it's a big departure from C++ where casting is to be avoided > if possible, and you're right that the cast isn't safe in general. It's > semi-reasonable because it's safe unless you cast somewhere and the C++ > multi-threaded programming model is unsafe anyway. But it's bad that the > bugs introduced can be quite far from the casts (e.g. if cast-to-unshared > data is placed in a global thread-local somewhere). > > But I don't see how you can do much of anything useful with shared data if > something like this isn't the plan. Tracking what data is protected by lock > and when is going to be outside of the scope of any type system you're going > to want for D (and is going to be undecidable in general). >
We're all still waiting to hear how D will handle locking under the covers. I don't think locking will be used to change types. A shared variable will always be shares, even if you have the lock.
