Re: [Reflex] Thread safety

Hi James,

not sufficient; the reflection database entries (i.e. the non-API type objects) themselves need to be thread safe. The singleton access itself is not really the issue. O and did I mention that I strongly prefer not to include boost as a dependency? :-)

Cheers, Axel.

On 2008-01-23 15:56, James Jackson wrote:
> If you're moving to a new implementation, there's a Boost library under
> review that very easily provides thread-safe singletons. I.e. your class
> definition:
>
> class MyClass
> {
> protected:
> int _member;
> };
>
> becomes:
>
> class MyClass : public boost::mutexed_singleton<MyClass>
> {
> public:
> MyClass(boost::restricted);
>
> protected:
> int _member;
> };
>
> and voila you have a thread safe singleton class for no extra effort.
> Perhaps worth looking in to?
>
> Regards,
> James.
>
> On 23 Jan 2008, at 14:52, Axel Naumann wrote:
>

>> 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
>>