harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: java.util.concurrent implementation
Date Tue, 24 Jan 2006 11:36:35 GMT
OK -- thanks Rodrigo.

Those types of atomic ops are not in the OSMemory type right now.  If we
get the concurrent code we can look at the full set of requirements and
implement them in classlib.


Rodrigo Kumpera wrote:
> util.concurrent needs two pieces of "unsafe" functionality: atomic
> operations like compare and set, compare and increment, etc; and field
> offset discovering needed by AtomicIntegerFieldUpdater, for example.
> The other parts don't require special handling besides LockSupport
> with would benefit from som changes in java.lang.Thread.
> On 1/24/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
>> AIUI the Unsafe type is Sun's means of manipulating OS heap memory --
>> classlib has a type that does that (currently in NIO module, and called
>> com.ibm.platform.OSMemory, though I agree with Paulex that it should
>> move into LUNI).  If the functionality of OSMemory is lacking we can, of
>> course, extend it to support concurrent.
>> Regards,
>> Tim
>> Rodrigo Kumpera wrote:
>>> Can we import the backport of jsr-166 as the starting point for
>>> implementing this package? It's released as public domain, so there
>>> should be not license issue IFAIK.
>>> There are only a few things required make it work, like removing
>>> references to com.sun.Unsafe.
>> --
>> Tim Ellison (t.p.ellison@gmail.com)
>> IBM Java technology centre, UK.


Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

View raw message