[thread] thread-safe static local
Hi, I need a function 'get_default_X()' returning a reference to a singleton in a multithreaded env. I choosed Scott Meyers singleton pattern (static local) together with boost::call_once(). My this be a reasonable, threadsafe implementation? regards, Oliver -- Computer Bild Tarifsieger! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 ¿/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
Oliver Kowalke wrote:
I need a function 'get_default_X()' returning a reference to a singleton in a multithreaded env. I choosed Scott Meyers singleton pattern (static local) together with boost::call_once(). My this be a reasonable, threadsafe implementation?
Hi Oliver, I wasn't able to see your implementation because the mailing list server still creates these broken links:
Hi,
As you may know, gcc creates local statics that are thread safe by default. So I have a macro something like this:
#if __GCC__ #define THREAD_SAFE_STATIC(TYPE,NAME) static TYPE NAME; #else #define THREAD_SAFE_STATIC(TYPE,NAME) #error FIXME #endif
If your code can be used in the #else case, that would be great. I think it's important to use the gcc feature when available as the alternative will probably involve an unnecessary extra layer of locking.
Is there a way to reliably determine if the gcc's thread-safe local statics are enabled? If not, multithreaded library code that relies on that feature, for example, should hide static locals inside an out-of-line function/method in the odd event users of the library disable gcc's thread safe local statics for their own code through the '-fno-threadsafe-statics' command line option. HTH, -Ossama
Othman, Ossama wrote:
As you may know, gcc creates local statics that are thread safe by default.
Is there a way to reliably determine if the gcc's thread-safe local statics are enabled?
No, last time I looked there didn't seem to be anything. IIRC there's also no way to enable/disable it for individual variables using attributes.
If not, multithreaded library code that relies on that feature, for example, should hide static locals inside an out-of-line function/method in the odd event users of the library disable gcc's thread safe local statics for their own code through the '-fno-threadsafe-statics' command line option.
Yes, you need to do something like this if you can't require users to use the default setting. Phil.
----- Original Message ----- From: "Phil Endecott" <spam_from_boost_dev@chezphil.org> To: <boost@lists.boost.org> Sent: Wednesday, March 04, 2009 12:11 AM Subject: Re: [boost] [thread] thread-safe static local
Othman, Ossama wrote:
As you may know, gcc creates local statics that are thread safe by default.
Is there a way to reliably determine if the gcc's thread-safe local statics are enabled?
No, last time I looked there didn't seem to be anything. IIRC there's also no way to enable/disable it for individual variables using attributes.
If not, multithreaded library code that relies on that feature, for example, should hide static locals inside an out-of-line function/method in the odd event users of the library disable gcc's thread safe local statics for their own code through the '-fno-threadsafe-statics' command line option.
Yes, you need to do something like this if you can't require users to use the default setting.
Hi, the boost build chain can take care of both adding a feature no-threadsafe-statics, that will do the setting of the compiler flag -fno-threadsafe-statics and an additional define, e.g. BOOST_NO_THREADSAFE_STATICS. With other build chains, it will be enough to signal on the documentation that both must be correlated. Vicente
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 03 March 2009, Oliver Kowalke wrote:
Hi, I need a function 'get_default_X()' returning a reference to a singleton in a multithreaded env. I choosed Scott Meyers singleton pattern (static local) together with boost::call_once(). My this be a reasonable, threadsafe implementation?
I don't think so. Your once_flag is a local variable in Y's constructor, so I don't see that the call_once accomplishes anything. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmtYNcACgkQ5vihyNWuA4UJyACfciR5l1vbwg7wMPUISDIQUhoN AfYAoLbHeovjJsaKzRuY0lYSmF5l0E1F =E/Pf -----END PGP SIGNATURE-----
participants (5)
-
Frank Mori Hess -
Oliver Kowalke -
Othman, Ossama -
Phil Endecott -
vicente.botet