octave-maintainers
[Top][All Lists]
Advanced

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

Re: Thread-safety issues in QtHandles


From: Michael Goffioul
Subject: Re: Thread-safety issues in QtHandles
Date: Wed, 9 Nov 2011 13:13:03 +0000

On Tue, Nov 8, 2011 at 10:26 PM, Michael Goffioul
<address@hidden> wrote:
> 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?

Here's a complete patch for octave, implementing this new approach.
It's obviously less intrusive than the previous one; I made it
configurable and disabled it by default. I tested it on Linux and
although it's probably not as bullet-proof as using shared_ptr, it
seems to provide a level of safety that is satisfying for QtHandles: I
tried to launch mirone a couple of times and didn't get any crash. I
also timed it on Linux (compiled with "-g -O2"): without the patch,
the test suite runs in 94.53s, with the patch, it runs in 111.93s
(that is ~17% increase).

Michael.

Attachment: thread_safe_refcount2.bz2
Description: BZip2 compressed data


reply via email to

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