octave-maintainers
[Top][All Lists]
Advanced

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

Re: Passing variables up to the GUI


From: Michael Goffioul
Subject: Re: Passing variables up to the GUI
Date: Sun, 14 Apr 2013 16:19:18 -0400

On Sun, Apr 14, 2013 at 3:42 PM, Daniel J Sebald <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.
 
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.
 
 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.
 

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?

Michael.


reply via email to

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