Re: [Boost-users] thread-safe initialization for singleton

Subject: Re: [Boost-users] thread-safe initialization for singleton
From: David Irvine (david.irvine_at_[hidden])
Date: 2010-08-22 06:47:48

On Sun, Aug 22, 2010 at 11:00 AM, Kraus Philipp
<philipp.kraus_at_[hidden]> wrote:
>
> Am 22.08.2010 um 11:41 schrieb Mathias Gaunard:
>
> Le 22/08/2010 07:59, Philipp Kraus wrote:
>
> The first example http://www.boostcookbook.com/Recipe:/1235044 don't
>
> have static members,
>
> That doesn't change anything.
> A singleton with static members is kind of pointless though.
>
>
> because
>
> myclass is a class with is a master class of the Singleton.
>
> What is that supposed to mean?
>
>
> In my class
>
> I've got a static property of the boost mersenne twister and get the
>
> rase condition error on it's get method:
>
> boost::detail::backward_compatible_uniform_01<boost::random::detail::pass_through_engine<boost::random::mersenne_twister<unsigned
>
> int, 32, 624, 397, 31, 2567483615u, 11, 7, 2636928640u, 15, 4022730752u,
>
> 18, 3346425566u>&>, double>::operator()()
>
> I don't understand what this is supposed to mean either.
> Why not attach a testcase showing the problem?
>
> I have written my own random class, in which I use a static boost::mt19937.
> On a single thread always works fine, but on multithread I get race
> condition errors. So I would like to create a static member over all
> threads. My question should be "how can I create a static member over
> multithreads". During searching the web and reading articles, I think it's a
> bad idea to do that. I have re-written my class and change the static member
> to a non-static member. Now every thread gets his own object and I don't run
> into race conditions
> Thx
> Phil
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>
In this case, could you not have had a shared pointer (on the heap)
that points to your object, you can then set up appropriate mutex's. I
would imagine it depends on the size of the object, so multiple
members verses wait conditions for locks is perhaps the consideration
(could the object be smaller). I would have thought initialising the
member instead as a variable (if it's just an rng, don't put it in the
object) in a  namespace with a header guard would work.