Shared Hell

[dsimcha]

== Quote from Walter Bright (newshound1 at digitalmars.com)'s article
> 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).
> I don't understand. Are you running multiple threads? Are those threads
> accessing globals?
> A function that accesses shared data has to put in fences. There's no
> way to have the same code deal with shared and unshared code.
> As an escape from the type system, you can always cast away the
> shared-ness. But I wonder about code that both uses global variables
> shared across threads that don't need synchronization?

I have at least one use case for __gshareds in multithreaded code.  I often use
__gshared variables to hold program parameters that are only set using getopt at
program startup and never modified after the program becomes multithreaded.

That said, although I use D2 regularly, I basically have ignored shared's
existence up to this point.  The semantics aren't fully implemented, so right now
you get all the bondage and discipline of it without any of the benefits.  As far
as the problem of synchronized methods automatically being shared, here's an easy
workaround until the rough edges of shared are worked out:

//Instead of this:
synchronized SomeType someMethod(Foo args) {
    // Do stuff.
}

// Use this:
SomeType someMethod(Foo args) {
    synchronized(this) {
        // Do stuff.
    }
}