Re: [boost] first steps to submitting - boost :: observers

Subject: Re: [boost] first steps to submitting - boost :: observers
From: Robert McInnis (r_mcinnis_at_[hidden])
Date: 2016-09-18 18:53:45

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?

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.

> 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.)

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].

done.

> The thread_self() and thread_pid() functions can be replaced by
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 <stdint.h> 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