On 09/17/2016 08:10 PM, Robert McInnis wrote:
What are the advantages of this library over Boost.Signals2 [1]? Same question with regards to the Boost.Synapse [2] proposal. My impression from a brief look at your repository is that you need to focus more on thread-safety. Is there any way to avoid the overhead of thread synchronization in a single-threaded application? Observers are invoked while the mutex is locked, so observers cannot make calls on the subject. How does the lock-free mutex perform, especially when congested? Why is the lock-free mutex recursive? There are several member variables that are used as if they are atomic but they are not declared as such, e.g. Subject::_block, Numeric<T>::_x (think T == long long.) The Scope template can be replaced by lock_guard if you model the LockFreeMutex after the BasicLockable concept [3]. The thread_self() and thread_pid() functions can be replaced by this_thread::get_id(). Replace the hAtomic macro with a type alias. Use <cstdint> instead of <stdint.h> to reduce polution of the global namespace. [1] http://www.boost.org/doc/html/signals2.html [2] http://zajo.github.io/boost-synapse/ [3] http://en.cppreference.com/w/cpp/concept/BasicLockable