On Sunday, September 18, 2016 6:50 AM, Bjorn Reese wrote:
What are the advantages of this library over Boost.Signals2 [1]?
Afaik, Signals2 is not meant to be associated with a single instance of a single object representing a particular event produced by that object.
Same question with regards to the Boost.Synapse [2] proposal.
I do not have boost::Synapse in 1.61. I did find it searching the site. Looking through its documentation, it seems to allow for the production of events within the object instance as well as producing numerous types of events, so that would be similar. I am unfamiliar with how it is implemented as the emitter seems to have to match the observer and if done on each trigger, that would be very costly. This also implies there is a large container of signals, indexed by source object ptr.
My impression from a brief look at your repository is that you need to focus more on thread-safety.
I believe all list manipulations have been protected, though I will go back and check. Specifying the template types as atomic will be updated.
Is there any way to avoid the overhead of thread synchronization in a single-threaded application?
The lock-free mechanism is as low overhead as can be without compiling out the mutex locks. I could add a compiler wrapper for single thread if you know a standard compiler wrap to use (ie: __SINGLE_THREAD, but that doesn't exist)
Observers are invoked while the mutex is locked, so observers cannot make calls on the subject.
Readers may read the value but updaters are restricted. Which is as it should be.
How does the lock-free mutex perform, especially when congested?
Under tests, it performs better than the standard mutex, as is expected. Keeping updates while locked to nonblocking/quick operations will keep the spin to a minimum.
Why is the lock-free mutex recursive?
There are several member variables that are used as if they are atomic but
By using the thread-id as the lock value, there can be situations where my own thread could try to update the same value again. Instead of dead locking, I allow for it to continue, which normally won't trigger a callback due to the value not being different. If the value did change, then the rule logic is circular and should be corrected by the developer. they are not declared
as such, e.g. Subject::_block, Numeric<T>::_x (think T == long long.)
Gotcha. I've made the change and will check it in.
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
done. this_thread::get_id(). can't really do that as I need to use the id as a value to set and compare. The thread_id returned by get_id is an object that doesn't allow for retrieval of the id.
Replace the hAtomic macro with a type alias. Use <cstdint> instead of
to reduce polution of the global namespace.
done and done. [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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost