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