octave-maintainers
[Top][All Lists]
Advanced

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

Re: Locking graphics system - GUI/octave synchronization


From: Michael Goffioul
Subject: Re: Locking graphics system - GUI/octave synchronization
Date: Sun, 20 Jul 2008 09:57:40 +0200

On Sun, Jul 20, 2008 at 4:59 AM, John W. Eaton <address@hidden> wrote:
> On 18-Jul-2008, Jaroslav Hajek wrote:
>
> | I guess you have 32-bit int, right? If so, then I think I understand
> | the problem:
> | when ~octave_mutex() is called on the "pointer" object, and rep->count
> | is decremented
> | to zero, `delete rep' calls again the same destructor which test
> | rep->rep, not rep->count!!
> | If only count is initialized and rep is wider, then it is easily
> | possible for count to be zero while rep is nonzero.
> | The trick of using the same class for both rep and pointer is cute but
> | took me some time to understand ;)
>
> Ah, you're right.  As I recall, this design is presented Coplien's
> Advanced C++ book.  The ideas there may still be OK, but by now I
> think most of the code is probably fairly outdated, and in this
> particular case, the way that rep and count are used is a little
> suspect.  We originally used the same method for the octave_value
> class, but reorganized it some time back.  I've now checked in some
> changes to make the mutex class look more like the current
> octave_value class.

Wouldn't be enough to just initialize both rep and count to 0 in
the protected constructor? The rest should then work OK.
I used it, because it avoided me to define 2 classes.

Note that I used the same design for gh_manager::event_data,
so the initialization should be adapted.

Michael.


reply via email to

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