Re: [Reflex] Thread safety

Hi Jean-Francois,

I am currently replacing the platform dependent hash map implementation with a generic one. The static member functions you refer to are moved to a new class (Catalog) that implements a singleton for now, and will be a per-process singleton and a per-thread "singleton" in the future to allow for per-thread types for a future _threaded_ interpreter. The latter doesn't need thread safety support, only the per-process one does.

Still, I plan to _allow_ that self-made hashmap to be thread safe (i.e. either with or without locks), now that it's fully under my control :-) I will not use the Intel TBB because it's overkill and because I prefer not to depend on outside libraries (e.g. I don't see solaris anywhere in the TBB pages :-)

So: if you can wait for a few weeks then please check out the new reflex. And if you need multi-threading support before we do I'd be extremely pleased to see a patch for Reflex's new hash map adding thread safety :-)

Cheers, Axel.

On 2008-01-23 15:33, Jean-Francois Bastien wrote:
> Good morning,
>
> I've been digging a bit in the Reflex implementation code and I've
> noticed that Reflex doesn't seem to be fully thread safe: classes
> named <something>Name (such as ScopeName, TypeName and others) all
> have a Name2<something>_t typedef which is either a hash_map or a
> hash_multimap. These hash maps are accessed through a singleton:
>
> static Name2<something>_t & s<something>() { static
> Name2<something>_t t; return t; }
>
> This is troublesome when user code is registering types because hash
> maps aren't inherently thread safe for writing (correct me if I'm
> wrong), and because the construction of the static method variable
> (the singleton implementation) isn't thread safe either. This means
> that parallel loading of multiple DLLs which have generated _rflx.cpp
> files compiled in them causes race conditions.
>
> Later access of the registered types is thread safe, though, because
> the containers are only being read.
>
> Am I wrong? Has any though been put into this? Are there already
> plans to make this thread safe?
>
> The easiest solution I see is that Intel's Threading Building Blocks
> has thread safe hash maps, and it's under the GPL with the runtime
> exception (if I'm not mistaken this is compatible with the LGPL of
> Reflex).
>
>
> Thanks,
>
> Jean-François Bastien
>
>
Received on Wed Jan 23 2008 - 15:52:26 CET