Shared Hell

[Denis Koroskin]

On Wed, 28 Oct 2009 16:19:11 +0300, dsimcha <dsimcha at yahoo.com> wrote:

> == 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.
>     }
> }

Yes, I've though about it. That's probably the only workaround for now and  
I'll give it. Thanks.