Re: Hotspot Identification

[Daniel J Sebald]

On 8/14/19 2:26 AM, John W. Eaton wrote:
> On 8/14/19 1:33 AM, Daniel J Sebald wrote:
> > On 8/13/19 5:21 PM, Rik wrote:
>
> > > The requirement for atomic refcounting was introduced by 
> > > communication with
> > > the GUI.  This brings up a hard question, is there a better way to
> > > implement cross-thread communication?
> >
> > I believe so.  Signals/slots are thread safe.  One can declare an 
> > octave_value/octave_value_ptr as a QObject then shuffle it across a 
> > signal/slot.
>
> I'm not sure what you mean by octave_value_ptr.
>
> Objects used as arguments in signal/slot functions don't have to be 
> QObjects.  Are you thinking of how they must be declared and registered 
> as meta types for Qt?

Yes, declare it near the top of the objects definition; but right, it 
doesn't have to be derived from a Qt object.


> Requirements for passing objects across threads are just that they have 
> to have a public default constructor, a public copy constructor, and a 
> public destructor.  Requirements are explained here:
>
>    https://doc.qt.io/qt-5/custom-types.html
>
> If the object uses reference counting, then operations on the reference 
> count must be thread safe.  Using atomic operations for reference 
> counting is more efficient than using mutexes.  If you share data with a 
> reference counted class and need to modify the shared data in multiple 
> threads, you'll need to protect the sections of code that modify data. 
> With Octave's copy-on-write semantics for things like octave_value and 
> Array objects, we don't have to worry about that, because any operation 
> that will modify a value will first force a copy and the thread that 
> will modify the data will own the copy.
>
> I think atomic reference counting is the right thing to do for these 
> types when they could be used across threads.

I remember this.  That reference counting wasn't a safe thing across 
threads; I tested it.  But when I passed the pointer to the 
octave_value, it had no affect on the reference count.  With that, the 
GUI can momentarily copy that octave_value data given the pointer, and 
let the worker thread continue on its way after the copy is done. 
Rather than a mutex, it is like suspending the worker thread for a moment.

Yes, there is some CPU wasted copying the data and holding it in the GUI 
until no longer needed (not difficult to program though).  But it avoids 
reference counting across threads.  Plus it means the GUI needs another 
level of sophistication.  It depends on what the goal is with the 
GUI--to be a super efficient realtime demo-like device?  Or a little 
more simple simple to program?  Not implying it couldn't have 
sophisticated features, just that streaming live data from a serial port 
through the system would be a lot of work.


> If we want to experiment with other solutions, what about introducing 
> move constructors and move assignment operators?  When working with a 
> single thread, that is most often what we want anyway, isn't it?  Can't 
> we define those as well as copy constructors and assignment operators 
> that share resources using reference counting and copy-on-write 
> semantics as before?  Would that help?

Yes, possibly.  In fact, copying/moving is akin to what I described 
above; just a little more sophisticated.  But I think the movement 
should still revolve around that octave_value.  That way, if one is used 
to programming Octave functions in the core, it's essentially the same 
sort of knowledge in the GUI.


> I can try to find or define an example class that does what I'm thinking 
> about in the next day or two.

OK, sounds good.

Dan