Re: [Reflex] Thread safety

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
>
Received on Wed Jan 23 2008 - 15:56:51 CET