VarHandles on non-int-sized fields and atomic operations

[David Holmes]

Expansion ...

On 24/05/2016 4:50 PM, David Holmes wrote:
> On 24/05/2016 9:20 AM, Martin Buchholz wrote:
>> On Mon, May 23, 2016 at 3:48 PM, Aleksey Shipilev
>> <aleksey.shipilev at oracle.com> 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.

... and you need to know how to form the correct mask.

David
-----


>
> 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