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.
-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: [email protected] > 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: [email protected] > > > 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]
