From owner-freebsd-arch Tue Dec 12 14:30:35 2000 From owner-freebsd-arch@FreeBSD.ORG Tue Dec 12 14:30:33 2000 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 3139337B400 for ; Tue, 12 Dec 2000 14:30:32 -0800 (PST) Received: from bissau-13.budapest.interware.hu ([195.70.53.141] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 145xwM-0006jE-00 for ; Tue, 12 Dec 2000 23:30:30 +0100 Sender: julian@FreeBSD.ORG Message-ID: <3A36A6E3.6507A6C0@elischer.org> Date: Tue, 12 Dec 2000 14:29:55 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: arch@freebsd.org Subject: [Fwd: Re: MEXT_IS_REF broken.] Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hmm having thought a bit more about this: > > http://www.FreeBSD.org/~jhb/patches/refcount.patch --------- I said: this is great but if I understand it, there is a hole... the operations are atomic, but if teh count is 1 and the release and aquire are called at around the same time, then thre are two possibilities.. the value goes 1 -> 2 -> 1 (this is ok) the value goes 1 -> 0 -> 1 ( this is NOT ok) the aquire calls atomic_add_acq_int(count, 1); which by my reading of the code last week, compiles down to lock ; addl (mumble) if the value that the aquire finds is 0 then it should fail and return without incrementing.. the returned value of 0 for the other processor will cause it to garbage collect the object in a very sort amount of time so trying to use it is a bad idea. Am I missing something here? Hopefully there si some higher level lock or something that stops you from trying to reference an object that is having its last reference removed (otherwise how did you find it?) but never-the less, it's an issue to look at. --------- end quote: thinking about this.. you should never be adding a reference to something that you don't already have a reference to, because you must have followed a reference to find the object in the first place. Thus if you are trying to add a reference and takeone away at the same time, you must have followed the reference that is being removed, which suggests a locking problem somewhere. In other words, detection of a 0 in the count at the beginning of a reference aquisition should be cause for a panic, or at least a heaavy diagnostic of some kind, and for certain it shound fail. -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message