1

Lets say I have the next method:

public synchronized void remap(UnaryOperator<X> update) {
    this.memory = update.apply(this.memory);
    inferDispatch();
}

Where memory is a volatile X variable;

In order to update X I could either setX(X x), which I already have as an option. But I also need to "remap" it from within, while being super ligthweight (I dont want to use AtomicReference).

Another option is..., instead of UnaryOperator, to use a Consumer, of course the requirement is that whatever operation is defined within the consumer cannot be done concurrently...

So What If the target of the method is an AtomicReference, the idea is that Memory being a ligthweigth class, does not have full thread safety properties, so can it inherit them? :

Memory<AtomicReference<X>> memory = new Memory(new AtomicReference());

memory.remap(xAtomicReference -> {
                            xAtomicReference.updateAndGet(
                                    x -> operator.transform(xAtomicReference.get())
                            );
                            return xAtomicReference;
                        }
                );

This would be a case where a "remap" would be beneficial, but the this.memory = update.apply(this.memory); is not giving me any confidence.

I am assuming that which ever thread that .getMemory().get()'s (The second get() is from the AtomicReference itself) a reference to memory, loses the atomic properties when the remap() is performed, since the "=" operand reassigns the volatile X varibale...

Should I use a Consumer instead of an UnaryOperator ??

Delark
  • 1,141
  • 2
  • 9
  • 15
  • 1
    your method is already `synchronized`; if the read of `memory` happens via the same lock - you should be good, even without `volatile` – Eugene Apr 06 '21 at 20:30
  • Thanks @Eugene I will sneak a question that I've always had but never had a succinct answer, I hope you dont mind.., Does "volatile" for reads, plus "synchronized" for writes equals AtomicReference barebone functionality? – Delark Apr 06 '21 at 20:33
  • 1
    no. the `JLS` guarantees happen for _pairs_ of read/write against the same constructs. – Eugene Apr 06 '21 at 22:55

0 Answers0