Static problem

Steven Schveighoffer schveiguy at
Thu Oct 7 13:26:54 PDT 2010

On Thu, 07 Oct 2010 16:18:26 -0400, Stanislav Blinov  
<stanislav.blinov at> 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:



More information about the Digitalmars-d-learn mailing list