From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7295 invoked by alias); 19 Dec 2010 18:49:48 -0000 Received: (qmail 7285 invoked by uid 22791); 19 Dec 2010 18:49:47 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_BJ X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 19 Dec 2010 18:49:42 +0000 From: "js-gcc at webkeks dot org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libobjc/47012] nonatomic Properties behave wrong X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libobjc X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: js-gcc at webkeks dot org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Sun, 19 Dec 2010 18:49:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-12/txt/msg02301.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47012 --- Comment #2 from js-gcc at webkeks dot org 2010-12-19 18:49:39 UTC --- Hi Nicola, yes, I do remember our talk at FOSDEM and I plan to attend it next year again, since I unfortunately could not attend it this year. Well, I guess it's not really like this because everyone felt this is better, I guess it is because Cocotron was the first to implement it (IIRC), then GNUstep looked how they solved it and now GCC looked how GNUstep solved it ;). I think it's not a bug, but intended, as not only the Apple runtime handles it like that, but the doc also says it's "just a return". So the documented behaviour and the real behaviour are in sync, I guess the name "nonatomic" was just a bad choice and the real idea was to have a way to create a lightweight accessor which is mostly used internally. There are several hints that nonatomic is thought for internal use in the formulations used by Apple. Plus, if you care that much about performance that the spinlock is too much for you, then autoreleasing would definitely also be a problem for you ;). I mostly use nonatomic in some special cases like exceptions where the object which caused the exception should not be retained and autoreleased to prevent exception-loops (for example, if autorelease caused the exception to be thrown, that'd be a problem here). In the code you linked, is that objc_mutex_t a spinlock? If not, this might be performance problem. Speaking of performance and contributing: I wrote my own runtime some time ago. The lookup is twice as fast as in libobjc in my tests (with ASM enabled even more). Maybe we could work on merging that into libobjc on next FOSDEM? I mostly wrote my runtime because there weren't any changes in the GNU runtime for a long time and I was happy to see that things finally changed with gcc 4.6 :). If you want to have a look: https://webkeks.org/hg/objfw-rt (Hint: Thread-safety is still missing, though the data structure for the lookup only needs a write-lock and no read-lock and can still be read while it is written and it's also missing exceptions (copying the exception.c from GNU libobjc works)) I think it would be great to also work with the guys from Clang. I think it would only make sense to have the same runtime on all non-Apple systems, regardless of the compiler.