www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: Semantics of shared

reply Matt <gelfmrogen yahoo.com> writes:
Matt Wrote:

 Is there some way to cast shared to thread local when a local has been
acquired?

It occurs to me that your plan is probably: with an explicit cast when the lock is acquired. So in practice 'unshared' is really going to mean something more like 'exclusively owned' and these modifiers aren't really going to help with managing what data is actually thread local vs. in the global heap. The purpose of the 'shared' annotation is then just to warn you about unlocked data and to serve a similar purpose as 'volatile' for code generation. Is this about right?
May 14 2009
parent reply Jason House <jason.james.house gmail.com> writes:
Matt Wrote:

 Matt Wrote:
 
 Is there some way to cast shared to thread local when a local has been
acquired?

It occurs to me that your plan is probably: with an explicit cast when the lock is acquired. So in practice 'unshared' is really going to mean something more like 'exclusively owned' and these modifiers aren't really going to help with managing what data is actually thread local vs. in the global heap. The purpose of the 'shared' annotation is then just to warn you about unlocked data and to serve a similar purpose as 'volatile' for code generation. 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.
May 14 2009
parent reply Matt <gelfmrogen yahoo.com> writes:
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).
May 14 2009
next sibling parent Jason House <jason.james.house gmail.com> writes:
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.
May 14 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Matt wrote:
 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).

It's not all bad. The huge advantage with "shared" is when you do a code review, it points you to where the potential trouble spots are. With the implicit sharing in C/C++, the whole program is a trouble spot.
May 14 2009