[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Thread-safety issues in QtHandles
From: |
John W. Eaton |
Subject: |
Re: Thread-safety issues in QtHandles |
Date: |
Mon, 31 Oct 2011 14:02:37 -0400 |
On 31-Oct-2011, Michael Goffioul wrote:
| On Mon, Oct 31, 2011 at 4:27 PM, John W. Eaton <address@hidden> wrote:
| > OK, maybe this is why Jaroslav created the octave_refcount class. He
| > never explained that to me. It might have been that he wanted to move
| > in this direction but while preserving the interface in which we still
| > have a count object.
|
| Maybe this is the case. But to ensure thread safety,
| incrementing/decrementing the refcount must be an atomic operation at
| CPU level. I suppose the implementation is highly architecture
| dependent. As this problem has already been solved in shared_ptr, I
| think it's better to use it instead of trying to re-invent the wheel.
| That's why I started to look at shared_ptr.
Right, I'm not saying that we should write our own, I just meant to
point out the history of the octave_refcount class. Previously the
reference count was always just an int, and the current
octave_refcount class doesn't really do anything more than can be done
with an int, so I wasn't sure why Jaroslav introduced the class. I
was just guessing that maybe he was thinking about trying to use it to
implement some kind of thread safety or some other feature that he
never explained. I asked once, but he did not reply.
| See attachment. Note that I modified foo::doit as I think it was a
| mistake to return "*this". The pattern as shown in the attached file
| is what I'm currently trying with octave_value/octave_base_value. For
| consistency/safety, I also changed the signature of functions
| returning octave_base_value* (like clone, unique_clone...). Of course,
| this impacts any class inheriting from octave_base_value.
OK. I'd be in favor of the change as it seems to make things somewhat
cleaner (as I said, I never liked having to manipulate count directly,
it's just that I didn't know what else to do). I think it will help
if we can explain clearly to people who may have derived from
octave_base_value exactly what they need to do to fix their code.
| Note that my goal is to provide make octave more thread-safe and solve
| the issues I have in QtHandles. Once I've completed the changes, I'll
| test them in QtHandles and check whether the issues are actually
| solved. If there are not, there will probably be no point in
| integrating those changes in octave.
OK.
jwe
- Thread-safety issues in QtHandles, Michael Goffioul, 2011/10/28
- Re: Thread-safety issues in QtHandles, Michael Goffioul, 2011/10/30
- Re: Thread-safety issues in QtHandles, John W. Eaton, 2011/10/31
- Re: Thread-safety issues in QtHandles, Michael Goffioul, 2011/10/31
- Re: Thread-safety issues in QtHandles, Michael Goffioul, 2011/10/31
- Re: Thread-safety issues in QtHandles, John W. Eaton, 2011/10/31
- Re: Thread-safety issues in QtHandles, Michael Goffioul, 2011/10/31
- Re: Thread-safety issues in QtHandles,
John W. Eaton <=
- Re: Thread-safety issues in QtHandles, John W. Eaton, 2011/10/31
- Re: Thread-safety issues in QtHandles, Michael Goffioul, 2011/10/31