Static problem

[Steven Schveighoffer]

On Thu, 07 Oct 2010 16:18:26 -0400, Stanislav Blinov  
<stanislav.blinov at gmail.com> wrote:

> Bob Cowdery wrote:
>
>>>
>>> Could you please post the use case as well? It should matter not from
>>> what module you make the calls, as long as those calls are from the
>>> same thread. Different threads get different copies of the registry.
>> I suspected that might be the case. Yes they are from separate threads.
>> No conflict as one writes all the tids and the others only read them.
>> What's the best way to fix that?
>>
>
> I wouldn't be too quick to state that there is no conflict, as  
> associative array access/lookup is most probably not an atomic operation.
>
> What I'd propose is either:
> 1) Create your own lock-free associative array (yup, reinvent the wheel  
> to introduce AA to the world of 'shared')
> 2) In this small case it may seem best (though mind that often such  
> cases do grow up to the point when you still need to rethink design):
> Make your associative array __gshared and perform synchronization by  
> hand, i.e. create a static Mutex (from core.sync.mutex) variable and  
> initialize it in your CRegistry's static ctor, and then enclose all  
> access to associative array in synchronized(mutex) {} blocks.
>
> Maybe concurrent-programming-in-D guru may propose simpler solution, but  
> I don't see another.

FWIW, the classinfo of a class is an object, and as such can be used as  
sort of a global lock without having to use a static constructor:

synchronized(this.classinfo)
{
    ....
}

-Steve