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: John W. Eaton
Subject: Re: Thread-safety issues in QtHandles
Date: Sat, 3 Dec 2011 05:47:17 -0500

On 28-Nov-2011, Michael Goffioul wrote:

| On Mon, Nov 14, 2011 at 7:48 PM, Michael Goffioul
| <address@hidden> wrote:
| > On Wed, Nov 9, 2011 at 1:13 PM, Michael Goffioul
| > <address@hidden> wrote:
| >> 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).
| >
| > Any update on this one?
| >
| > Did anybody give it a try, for instance on amd64 or Mac OS X?
| >
| > Michael.
| 
| Ping?
| 
| Is it deemed to be left in limbo?

Sorry for the delay.

On my system with the current sources from the mercurial archive, I
see the following time for running the tests (default -g -O2 compiler
options):

  62.17user 13.01system 1:21.17elapsed 92%CPU

With your thread_safe_refcount2 patch applied and using the
--enable-atomic-refcount configure option, I see:

  71.35user 13.07system 1:29.95elapsed 93%CPU

That gives total CPU times of 75.18 (without) vs. 84.42 (with), or
about 13% longer to run the tests with the atomic refcount code
enabled.

That still seems like a large penalty, but I agree with Michael
Godfrey that it is OK to apply now, but should perhaps be left
disabled by default for the 3.6 release.

jwe


reply via email to

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