Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.chainon-marquant.org!nntpfeed.proxad.net!proxad.net!feeder2-2.proxad.net!nx01.iad01.newshosting.com!newshosting.com!216.196.98.146.MISMATCH!border3.nntp.dca.giganews.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.earthlink.com!news.earthlink.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 09 Jan 2012 12:57:00 -0600
Date: Mon, 09 Jan 2012 10:56:52 -0800
From: Patricia Shanahan <pats@acm.org>
User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
Newsgroups: comp.lang.java.programmer
Subject: Re: Atomic integer array class question
References: <9d7d89a6-3109-412f-a898-e2c9e82b780b@cs7g2000vbb.googlegroups.com> <jef22t$oc9$1@dont-email.me> <803273c0-b874-4d53-a9f7-70cbefac5ddd@k5g2000vba.googlegroups.com>
In-Reply-To: <803273c0-b874-4d53-a9f7-70cbefac5ddd@k5g2000vba.googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <L4SdnYBDN4fhpZbSnZ2dnUVZ_gudnZ2d@earthlink.com>
Lines: 80
X-Usenet-Provider: http://www.giganews.com
NNTP-Posting-Host: 75.11.53.36
X-Trace: sv3-jGbp2WBCseIESAk7rwYTa8MaLkozOXyOXFjKS91uwTcrEOxUcWWyhfEsNFvOsa7Oh5P5X5ODEEv8VGC!PAKN202xMCsehYiNCxdaestBpj7sh9g56vM4oL0wPqX37eTKfehaU4T4pQvO17hiapMkckNySTRY!dX09oM1jxD4SZYIxx8bt270kcUXjfrW1oITYT9Q6NFg=
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 4086
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:11136

On 1/9/2012 8:17 AM, raphfrk@gmail.com wrote:
> On Jan 9, 3:45 pm, Knute Johnson<nos...@knutejohnson.com>  wrote:
>> Read the package description for java.util.concurrent.atomic to get a
>> good idea of what the Atomic variables are.  But no the performance will
>> not be as good as a regular array.
>
> Sorry, I wasn't clear, I didn't mean compared to a regular array.
>
> AtomicIntegerArray intArray = new AtomicIntegerArray(10);
>
> compared to
>
> AtomicInteger[] intArray = new AtomicInteger[10];
>
> If 2 writes happen to an AtomicIntegerArray, but at different
> locations, do they interfere?
>
>> Why don't you post something about what you are really going to do with
>> the array and maybe somebody can give you a better idea of what way to go.
>
> I was wondering if having writes to an array happen one at a time
> would be slower than an AtomicIntegerArray.

I don't understand this comment. Each AtomicIntegerArray operation
refers to a specific element, so writes must happen one at a time anyway.

>
> Something like (though not actually for int arrays, as then I would
> just use AtomicIntegerArray)
>
> private final int UNSTABLE = 0;
> int[] array = new int[1000];
> AtomicInteger sequence = new AtomicInteger(1);
>
> public void set(int index, int value) {
>      while (true) {
>          int oldSequence = sequence.getAndSet(UNSTABLE);
>          if (oldSequence == UNSTABLE) {
>              continue;
>          }

Spin waiting, especially spin waiting that has no delay and includes
access to a volatile variable, can be very expensive in terms of load on
the processor-memory interconnect.

I would do some benchmarking, but are you sure this is better than
synchronization?

>          array[index] = value;
>          sequence.set(oldSequence + 2);
>          return;
>      }
> }
>
> public void get(int index) {
>      while (true) {
>          int initialSequence = sequence.get();
>          if (localSequence == UNSTABLE) {
>              continue;
>          }
>          int value = array[index];
>          int finalSequence = sequence.get();
>          if (initialSequence != finalSequence) {
>              continue;
>          }
>          return value;
>      }
> }
>
> So, the effect is that writes happen one at a time.  If a thread sets
> the sequence number to UNSTABLE, then all other writers will
> spinlock.  Also, if any element is changed, then all readers will
> detect it and have to retry (even though their data was actually not
> changed).

I'm still unclear what is intent, and what is infrastructure to do with
how you are trying to implement the intent. Could you provide a
description of what you want to have happen?

Patricia