「view this page in B3 βῆτα server」

Revisions №57331

branch: master 「№57331」
Commited by: Andrew Leaver-Fay
GitHub commit link: 「47fa00e8173e3e73」 「№108」
Difference from previous tested commit:  code diff
Commit date: 2014-10-02 17:32:08

Merge pull request #108 from RosettaCommons/aleaverfay/improved_singleton Changing the way singletons are declared for the sake of thread safety. Singleton class X must now do the following: 1) using CRTP, derive publicly from utility::SingletonBase< X > 2) define a private, static function X * create_singleton_instance(); 3) declare class utility::SingletonBase< X > to be a friend so that it (and no one else) can call create_singleton_instance() 4) include the following code block to define two static variables in X.cc: namespace utility { using my::namespace::X; #if defined MULTI_THREADED && defined CXX11 template <> std::mutex utility::SingletonBase< X > ::singleton_mutex_; template <> std::atomic< X * > utility::SingletonBase< X >::instance_( 0 ); #else template <> X * utility::SingletonBase< X >::instance_( 0 ); #endif } The SingletonBase class defines the static X * get_instance() function and handles the instantiation of the instance in a thread-safe manner. The instance_ pointer belongs to the base class. This commit leaves loud messages about some awful abuse of global data through singletons. Look for "WARNING WARNING WARNING! THREAD UNSAFE!" messages. Singletons, with certain explicit exceptions (the JobDistributor, the ResourceManager) should not hold job-specific data. Changing the InterchainPotential so that it no longer derives from core::scoring::EnvPairPotential, since it shares literally nothing with that class. This means that the data that EnvPairPotential loads in from the rosetta_database no longer gets loaded in twice, and thus causes a large number of cosmetic integration test changes. The match_1n9l integration test has continued to show the amino-acid-order instability that I thought I had gotten rid of, so I went and found yet another std::set< ResidueTypeCOP > in the enzyme design code that I've now eliminated. Hopefully that bug is now gone.

...