octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hotspot Identification


From: John W. Eaton
Subject: Re: Hotspot Identification
Date: Wed, 14 Aug 2019 02:26:56 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

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?

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.

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?

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

jwe



reply via email to

[Prev in Thread] Current Thread [Next in Thread]