Shared Hell

[Jason House]

Christopher Wright Wrote:

> Denis Koroskin wrote:
> > I've recently updated to DMD2.035 (from DMD2.031 because all the later 
> > versions had issues with imports) and for the first time faced problems 
> > with shared modifier.
> > 
> > I don't need shared and all my globals are __gshared (they are globally 
> > unique instances that don't need per-thread copies).
> > 
> > Yet some of methods of the class hierarchy (a root singleton class and 
> > everything which is accessible through it) are synchronized (well, you 
> > know why). That's where the problems begin.
> > 
> > Marking a method as synchronized automatically makes it shared (more or 
> > less obvious). And marking the method shared makes it unable to invoke 
> > with non-shared instance (and __gshared != shared), meaning that I'm 
> > unable to use my __gshared variables anymore, making this attribute 
> > useless for any serious safe programming.
> > 
> > So I started with replacing __gshared with shared and quickly understood 
> > how viral it is. Not only you mast mark all the members shared (methods 
> > and field), instantiate classes with shared attribute, you also have to 
> > create a duplicate all the methods to make them accessible with both 
> > shared and non-shared (thread-local) instances:
> 
> Why can't you use a non-shared method on a shared object? The compiler 
> could insert locking on the caller side.
> 
> Why can't you use a shared method on a non-shared object? The compiler 
> could, as an optimization, duplicate the method, minus the 
> synchronization. Or it could leave in the locking, which is expensive 
> but correct.

The caller would have to acquire locks for all the data accessed by the non-shared method and all non-shared methods it calls. Additionally, non-shared functions can access thread-local data. Neither of those issues are easily solved. Bartosz's scheme would solve the first one due to implied ownership.