On 6/18/06, Nathan Beyer <[EMAIL PROTECTED]> wrote:
Thanks. How does the Atomics class work in regards to volatile reads of elements of an array? Here's the class I'm looking at implementing with the Atomics API [1]. The CAS operations are trivial. It's the 'get' and 'set' methods that I'm trying to figure out.
Hi Nathan, Atomics in drlvm has a function MemoryReadWriteBarrier() defined in atomics.h (see http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/include/atomics.h) which can be utilized for implementing volatile reads and writes for AtomicIntegerArray. Some work, however, will still be needed for atomics.cpp to add volatile set() and get() implementations accessible through JNI interface. Another approach to implement AtomicArray.get and set could be via CAS operation. For example, for set() method, you simply can do something like: int orig = arr[i]; // guess original master value compareAndSet(i, orig, newValue); // set new value; if the original value is unexpected, it would just mean that someone else has changed it concurrently which is OK for this case and we just do nothing; For get() method, algorithm could be like: int orig = arr[i]; compareAndSet(i, 0, 0); // do CAS with whatever value, this ensures cache is flushed; return arr[i]; // return the master value In terms of the speed, it must be almost same as doing mfense, at least on IA32 (mfense is probably 20-30% faster). Thank you, Andrey Chernyshev Intel Middleware Products Division
-Nathan [1] http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concu rrent/atomic/AtomicIntegerArray.java?rev=1.19&only_with_tag=JSR166_PFD&conte nt-type=text/vnd.viewcvs-markup > -----Original Message----- > From: Artem Aliev [mailto:[EMAIL PROTECTED] > Sent: Friday, June 16, 2006 6:52 AM > To: harmony-dev@incubator.apache.org > Subject: Re: [classlib][vm] Prerequisites for java.util.concurrent > > Nathan, > > > VMI Atomicity/Lock API - All of the AtomicXXX classes are delegated to a > > VM-specific API for atomic gets and sets. This API will need to be > defined > > and then implemented by the various VMs. Many of the lock APIs also make > use > > of this API. > > I have done some experiments with concurrent in DRLVM. So there are > two kernel classes in the DRLVM that, probably, provide full set of VM > dependent > functionality required by util.concurrent. Both have special VM support. > > vm/vmcore/src/kernel_classes/javasrc/java/util/concurrent/locks/LockSuppor > t.java > -- park/unpark methods > > The special queue could be used in case you need to implement it in VM > independent way. > > vm/vmcore/src/kernel_classes/javasrc/org/apache/harmony/util/concurrent/At > omics.java > -- CAS operations on references, ints, longs etc. > > The methods are aware of internal object layout and reference format. > VM independent implementation could be done base on java monitors, but > it kills the idea of the util.concurrent. > > Thanks > Artem Aliev > Intel Middleware Product Division > > > > On 6/14/06, Nathan Beyer <[EMAIL PROTECTED]> wrote: > > I stubbed out the method in luni-kernel (as well as two other methods > that > > were missing). I looked at DRLVM and it already has nanoTime > implementation, > > but it's not using the method you mentioned. I took a peek at the > > JCHEVM/classlibadaptar, but I couldn't quite discern the various > artifacts. > > > > -Nathan > > > > > -----Original Message----- > > > From: Tim Ellison [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, June 13, 2006 6:34 AM > > > To: harmony-dev@incubator.apache.org > > > Subject: Re: [classlib][vm] Prerequisites for java.util.concurrent > > > > > > Nathan Beyer wrote: > > > <snip> > > > > Does this mean we can stub out the luni-kernel System and just get > the > > > VMs > > > > to implement it in their kernel classes using this method? > > > > > > That's what I was thinking, and we can implement it in the luni-kernel > / > > > classpathadapter as a reference for VMs if we so choose. > > > > > > Regards, > > > Tim > > > > > > -- > > > > > > Tim Ellison ([EMAIL PROTECTED]) > > > IBM Java technology centre, UK. > > > > > > --------------------------------------------------------------------- > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
