Re: Thread-safety issues in QtHandles

[Michael Goffioul]

On Mon, Nov 7, 2011 at 9:06 PM, Michael Goffioul
<address@hidden> wrote:
> On Mon, Nov 7, 2011 at 8:15 PM, John W. Eaton <address@hidden> wrote:
>> On  7-Nov-2011, Michael Goffioul wrote:
>>
>> | Clearly, there's a performance penalty, as using shared_ptr is heavier
>> | than simply count++. OTOH, the gain - thread-safety - is also non
>> | negligible.
>>
>> Yes, I don't expect to get that completely for free, but I was not
>> expecting a 25% increase in execution time.  To me, the bad thing
>> about this is it affects all users, not just those that care about
>> thread safety.  As far as I know, there is nothing in the test suite
>> that really depends on multiple threads.  So as a hypothetical user of
>> some code that doesn't rely on having multiple threads running in the
>> Octave interpreter, I would not like to see that code to suddenly be
>> 25% slower because of a feature I'm not even using and don't need.
>
> Fair enough. But I suspect the performance decrease is partially due
> to the nature of the test suite, which loads every single m-file. I'd
> be interested to see the same comparison for another type of benchmark
> like this one: http://sciviews.org/benchmark/Octave2.m (I'll give it a
> try tomorrow if I get some time).
>
> Now the question is: what do we do?

I've been experimenting a bit today and from callgrind output, it
looks like a part of the performance penalty is due to the additional
allocation/de-allocation of internal shared pointers, part of
shared_ptr implementation.

So I tried another approach: instead of using shared_ptr, implement
the same thread-safe operations directly on the existing "count"
member. This should avoid the additional new/delete calls. The big
drawback of that approach is that we're kind of re-inventing the wheel
and put compiler-/architecture-dependent code in octave. But if it
achieves the same goal without the performance penalty, I'm fine with
it.

The prototype is in attachment. It's based on the existing
octave_refcount class, but implements increment/decrement operators
using thread-safe compiler intrinsics (that's actually what shared_ptr
is doing internally, but with lot more stuff around it). I've added
support for MSVC and GCC, and I've tested it on Windows with MSVC and
MinGW. The test program seems to run OK: the final reference count is
1, which is what is expected.

I didn't have time to recompile octave with the modified
oct-refcount.h file and run the test suites, so I don't know what will
be the performance penalty. Hopefully, it'll be negligible. I'll test
that tomorrow.

What do you think?

Michael.

oct-refcount.h
Description: Text Data

test-refcount.cc
Description: Binary data