On 24/05/2016 9:20 AM, Martin Buchholz wrote:
On Mon, May 23, 2016 at 3:48 PM, Aleksey Shipilev
<[email protected]> wrote:
By the way, what exactly are you winning with 1-byte field in AtomicBoolean?
I'm not trying to replace the int field inside the AtomicBoolean with
a boolean - that's an implementation detail.
(Although I would take it if I could declare an atomic boolean inside
AtomicBoolean and let the JVM choose the best size for the platform.
It *is* a small weakness that we need to use the "int" type here in
java code)
I'm trying to allow regular programmers to declare their primitive
fields with the natural Java type and have all the atomic operations
available.
Not "any", int/long/reference VarHandles still do CASes. Note that the
current API does not preclude implementing CASes for other types if you
can come up with a plausible mechanics of doing so.
The thing is, there does not seem to be a plausible fallback strategy
when platform cannot do a subword CAS. Or at least I cannot see it.
Artisanal Unsafe.compareAndSwapBoolean implementations are welcome :)
As I said in a previous message, you can implement subword CAS using
fullword CAS in a loop.
cas8bit(expect, update) {
for (;;) {
fullword = atomicRead32()
if ((fullword &0xff) != expect) return false;
if (cas32(fullword, (fullword & ~0xff) | update) return true;
}
}
but it would probably be more efficient if a fullword was allocated
for the subword field.
The above will only work if the subword field is suitably aligned within
the word ie atomicRead32() needs to know the address of the subword of
interest.
I don't see the VarHandle situation as being any different from the
Atomic*FieldUpdater one. The practicalities of implementation
limitations shaped the API so that we don't give the illusion of
delivering something we aren't. My only problem with VarHandles is that
I can't see anything that defines when the various AccessModes are
unsupported. ??
Cheers,
David
