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