Why does a thread need an acquire fence to read a plain write it made to a resource it owns? [closed]

I uploaded the code for context as a gist here: https://gist.github.com/kusoroadeolu/ec8021ad8dd1d00ddde54effaeef5c23

I ran into an issue. I've potentially fixed it but its quite perplexing.

I added:

/*get_acquire read*/ if (ours.isApplied()) return ours.lpItem();

inside the lock before the combiner releases the lock. If I don't include a get_acquire read before reading the plain write as the combiner.

return ours.lpItem()

Only the combiner returns a false null in this scenario (a result that's not meant to be null) which could lead to issues. I understand why I have to use that get_acquire read for non combiners, but I'm confused why I need to do that for a combiner(the thread holding the lock)?

My current reasoning is that the combiner applies its own node during the scan with a plain write to item, and since it's the same thread reading it back, I'd expect program order to guarantee visibility without any sort of fence. Is there anything I am missing here?