c++ - Fast lock for variables that are read a lot and may be changed from another thread occasionaly -

i'm looking lock, allows thread-safe transition between gui , back-end.

just double, i'm sure end being used other things.

now part i'm unsure of, on modern cpus, can reading , writing @ same time cause race condition? or when 2 threads try write @ same time.

i've encapsulated variables cross threads with, in template object, allows me same use requires locking, here basics:

//===================================================================================================== // class store variable in thread safe manner. //===================================================================================================== template <class t> class threadsafevariable { public:    threadsafevariable(const t & variable):     _stored_variable(variable)   {   }    threadsafevariable():     _stored_variable()   {   }    //=====================================================================================================   /// returns stored variable   //=====================================================================================================   t read() const   {     boost::unique_lock<boost::mutex> lock(_mutex);     return _stored_variable;   }     //=====================================================================================================   /// sets variable   //=====================================================================================================   void operator = (const t &value_to_set)   {     boost::unique_lock<boost::mutex> lock(_mutex);     _stored_variable = value_to_set;   }     //=====================================================================================================   /// returns stored variable   //=====================================================================================================   operator t() const   {     boost::unique_lock<boost::mutex> lock(_mutex);     return (t) _stored_variable;   }     void setfromstring (const std::string & value_to_set);   t operator ++ (int);   t operator -- (int);   std::string tostring() const;    protected:   t _stored_variable;   mutable boost::mutex _mutex; }; 

would possible, make class faster, provided 1 thread given option of writing (that part needed encoded calling different functions).

basically i've got static function, want keep static varies based on parameter change on gui it's in performance critical part of software.

i'm aware of spin locks, atomics. have never used them. guess spin lock waste of cpu , i'm not sure of performance gains atomics.

you should take @ std::atomic<>, pretty implements precisely behavior need. don't reinvent wheel.

the nice thing std::atomic<> is, employs hardware facilities atomic reads , writes, basic instanciations of std::atomic<> lockfree, huge speed bonus. there few preprocessor macros signal of basic instanciations of std::atomic<> implemented in lockfree fashion, allows select best fitting lockless 1 (atomic_char_lock_free 1 of these, example).

---

the following explanation of possible race between read , concurrent write only. don't try read instructions doing outside of language standard. if ignore standard , nasal deamons appear, that's not in department.

regarding question whether there can race condition between read , and write, depends on circumstances. generally, can assume single read or write of naturally aligned type natively supported machine handled in atomic fashion. i. e., on 64 bit machine can expect reads , writes of uint64_t atomic if uint64_t aligned 8 byte boundary. if these conditions not met, may end in situation 1 half of value read memory comes value before write while other half comes value written. example, if this

while(1) {     myglobal = 0x0000000000000000;     myglobal = 0x0123456789abcdef; } 

concurrent to

printf("0x%016llu\n", myglobal); 

and myglobal not aligned, or run on 32-bit machine, might find output of 0x0123456700000000.

the c++ language defined in way ignores these implementation details, concurrent access of variable includes @ least 1 write considered race condition. bit far on safe side, existence of std::atomic<> acknowledges. it dangerous code relies on these guarantees not use std::atomic<>, because allows optimizer skrew assumptions of programmer (more information on can found in short article boehm.pdf , nosid link).

consequently, std::atomic<> way lockless, threadsafe variables blessing of c++ standard.