Re: Passing variables up to the GUI

[Daniel J Sebald]

On 04/14/2013 03:19 PM, Michael Goffioul wrote:
> On Sun, Apr 14, 2013 at 3:42 PM, Daniel J Sebald <address@hidden
> <mailto:address@hidden>> wrote:
>
>
>     Just trying to think this through, to avoid going down a coding path
>     that seems a bit clumsy right now.
>
>     Here is the critical hunk of code:
>
>        octave_value (const octave_value& a)
>          {
>            rep = a.rep;
>            rep->count++;
>          }
>
>     The issue with the little prototype I did isn't the rep count.  I
>     think that is fine.
>
>
> On the contrary, I think it's the heart of the problem. The line
> "rep->count++" is the critical one in the above code. While one thread
> is executing it, another one can be doing "rep->count++" or
> "--rep->count". Those operations are not atomic, takes several CPU
> cycles and can be interrupted by other threads. The problem is that the
> resulting values rep->count is then undetermined.

That's true if we're talking OS threads.  However, Octave is running in 
a QThread, not an OS thread.  I'm assuming that Qt has done some kind of 
magic behind the scenes to make that signal/slot mechanism work out. 
How do you know that the copy-constructor is done in one thread and the 
destructor is done in another thread?  Certainly it isn't a single slot 
influencing this.  There is a some mechanism that is calling a list of 
slots and then deleting the reference.  That reference is not deleted 
when any one particular slot is called.  Where that is done, I'm not 
sure.  That is why I said it depends on how Qt operates.


>     So the question is, will the Worker thread be modifying the data at
>     the same time that the GUI thread could be copying individual
>     elements, i.e., just using the octave_value, not actually copying
>     it?  Possibly the answer is "no".
>
>
> I think the answer is "yes". By simply writing:
>
>      Matrix m = ov.matrix_value();
>
> you are modifying data.

Yes, but that Matrix representation is associated with the octave_value. 
 If there is nothing in the worker thread that is going to touch that 
octave_value representation (that was a condition of what I proposed) 
then the GUI thread is free to increase the rep count, so long as it 
decreases the object's thread count before returning.

>       Or maybe it is easy to make that the case.  It seems to me if a
>     locally constructed octave_value can be made in the Worker thread,
>     then emited, the local destructor will happen, then later the slot
>     destructor will happen.  That is
>
>
> "Later" is irrelevant here. With multithreaded app, both destructors can
> happen at the same time, concurrently.

But when is that in the QThread environment?  Not generally speaking in 
the OS environment.  The important thing here is the signal/slot 
mechanism.  It may be that in order for this to operate properly, the Qt 
programmers took an approach whereby the constructor-copy and delete are 
done in the same thread.  For example

GUI issued signal
  copy object in GUI thread
  call all slots in the Worker thread
  delete object in the GUI thread

Worker issue signal
  copy object in the Worker thread
  call all slots in the GUI thread
  delete object in the Worker thread

I'm not sure that is correct, but I can't find the answer just yet.


>     1) Create a "local" duplicate of the octave_value in the routine
>     that processes the desired command, on the stack or via "new" or
>     whatever. That has a rep count of 1.
>
>     2) Emit the signal that creates a copy of that local octave_value,
>     thereby increasing the rep count to 2.
>
>     3) Destroy the local copy off the stack or via "delete".  That
>     brings the rep count back down to 1.  *And* from this point forward
>     there is no code inside the Worker thread that will touch the
>     representation data of the octave_value object because it has gone
>     out of scope to any remaining code in the thread.
>
>     4) Sometime later the slots are processed in the GUI thread and that
>     representation data still exists, unaltered by anything in the
>     Worker thread.
>
>     5) All slots finish, and Qt calls the destructor for the
>     octave_value. The representation count goes down to 0 and the data
>     is deleted from memory.
>
>
> What makes you think 3) and 5) won't be executed concurrently?

Your question is the critical one.  My supposition is hinged on the fact 
that Qt has to do something to make cross-thread signals work.  Hence 
they have this QThread class.  That question is still in air here.  I've 
searched the Internet for that answer, but haven't found any just yet.

Dan