Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (herse.apache.org: domain of justin.erenkrantz@gmail.com
 designates 64.233.182.188 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=D80f2FDv8+ksFTmiuVxT86B+Oad+utjZHwxQdDUGxHDuxEokmdj/xa1waQsRyNawzaG0x54bfWtxDO4ZskHAHRUpWiJ8SUDpzXNTHaUAHuf41Vbz9vKUUPbiJemxKstvhzMUEorzM4AgVtMcaA3ONXgEhBTX8xF16aCGWLj+Ldo=
Message-ID: <5c902b9e0610300028p21ebf300w66f121876ffb26a0@mail.gmail.com>
Date: Mon, 30 Oct 2006 01:28:04 -0700
From: "Justin Erenkrantz" <justin@erenkrantz.com>
Sender: justin.erenkrantz@gmail.com
To: mail@cohi.at
Subject: Re: Patch 1 for apr_atomic.c (Solaris 10)
Cc: Colin <share-apache@think42.com>, dev@apr.apache.org
In-Reply-To: <20061030082004.GA7671@p15097255.pureserver.info>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20061029102904.GA14669@p15097255.pureserver.info>
	 <5c902b9e0610292224r75b04dabs982fdb550806ac63@mail.gmail.com>
	 <20061030072112.GA6932@p15097255.pureserver.info>
	 <5c902b9e0610292358v2ce370f7r3aa898289e86e542@mail.gmail.com>
	 <20061030082004.GA7671@p15097255.pureserver.info>

On 10/30/06, Colin Hirsch <mail@cohi.at> wrote:
> > The both use 'mfence' on AMD64. The AMD x86-64 manual:
> >
> > http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24594.pdf
> >
> > 'mfence' is on page 182 of Vol 3:
>
> Aha, so we need a memory barrier on x86-64 too? The implementation currently
> seems to assume that the same rule as for x86-32 applies, namely that the
> architecture is NOT weakly ordered?

I don't profess to know.  But, AFAICT, both Intel and AMD CPUs support
the MFENCE op when in x86-64 mode.

> I haven't checked testatomic in depth, but it seems to test that the
> individual operations work correctly, but not whether all combinations
> of operations work correctly, otherwise it would have already found the
> issues that the patch tries to fix. The problem is of course that it is
> not so easy to test all operations, and all _combinations_, in a way
> that really breaks if there is a problem with the synchronisation...

Can we at least have it test the issues that this patch tries to fix?
Are they easily reproducable?

Thanks.  -- justin