proposal: atomic: add (*Value).Swap

[bcmills]

atomic.Value seems to be the preferred replacement for the atomic.*Pointer methods in code that avoids package unsafe. Unfortunately, atomic.Value doesn't support swaps, making it much less powerful than the equivalent Pointer methods.

When investigating sync.RWMutex usage in the standard library (#17973), I discovered an RWMutex in crypto/tls guarding two fields, sessionTicketKeys and originalConfig, that are always updated independently. It's trivial to replace sessionTicketKeys with an atomic.Value, but originalConfig needs an atomic swap.

More generally, it would be nice if atomic.Value were as complete a replacement as possible for unsafe.Pointer with atomic operations.

---

Adding CompareAndSwap was discussed previously (#11260).
The major arguments against at the time seem to have been:

1. Inapplicability for incomparable types. (sync/atomic: atomic.Value doesn't support CompareAndSwap #11260 (comment))
2. Lack of concrete use-case. (sync/atomic: atomic.Value doesn't support CompareAndSwap #11260 (comment))
3. Availability of unsafe.Pointer as an alternative. (sync/atomic: atomic.Value doesn't support CompareAndSwap #11260 (comment))

To address those points directly:

1. Swap, unlike CompareAndSwap, does not require comparability. (Personally I think it would be good to add CompareAndSwap too and simply panic for uncomparable types, but as I don't have a use-case for that I would prefer to keep it out-of-scope for this proposal.)
2. I have identified a concrete use-case in the crypto/tls package.
3. According to @bradfitz in CL 41930, unsafe.Pointer is strongly discouraged outside of the sync, runtime, and reflect packages.

(@dvyukov, @josharian, @OneOfOne, @cespare, @adg, @rsc)

[rsc]

I'm very skeptical that code in crypto/tls is even correct. What is going on there?

[ianlancetaylor]

The only time the field is set is immediately before calling newConfig.serverInitOnce.Do(newConfig.serverInit), so I think this code could be simplified by simply passing the originalConfig value as an argument to serverInit. As far as I can see originalConfig is being used to pass an argument through sync.Once.Do, but that is more easily done using a closure.

The field was added in https://golang.org/cl/30790. CC @agl.

[gopherbot]

CL https://golang.org/cl/42137 mentions this issue.

[agl]

Yes, it's passing an argument to the once function. https://go-review.googlesource.com/c/42137/ does the same thing with closures if that's useful.

[rsc]

Thanks @agl.

Given that CL 42137 eliminates the motivation for atomic.Swap, @bcmills do you have any other motivation for it?

[bcmills]

Not at the moment. If you'd like to shelve this until we find another use-case, that's fine with me.

[mlitvin]

My two cents

I had today a semi-real use case.

It was real because I was writing a code where I actually went and looked for Value.Swap because I wanted to use it and was a bit surprised not to find it.

However the fact that it is not there didn't blocked me, I my specific use case using simple locks instead of atomic value would most probably be doable without significant performance degradation of the whole system, and if it was critical I would probably be able to either use unsafe.Pointer, or fork atomic.Value.

The problem is that any of the solutions (including using locks) seems to be on the same order of complication as implementing Value.Swap.

So why not do it? The difference between Value.Set and Value.Swap is probably around 5 lines of code, its not a big burden for the standard library.

[dvyukov]

@mlitvin How do you use mutex? From your text it seems that you use mutex on both write side and read side. Value is meant for read-mostly scenarios. In such case, if you need swap, you put mutex only around write side and do Load+Store under the mutex, which effectively gives you Swap without any performance degradation (since it's read-mostly scenario), and code complexity is almost equivalent to Swap since this is all local to write side. This also saves you from potential atomicity violations between multiple writers (which are presumably present, since if there is only 1 writer, then Load+Store is equivalent to Swap).

[mlitvin]

@dvyukov, putting mutex only around the write side is a good trick (that I haven't thought of) and I may use it. Thanks!

That lead to a different suggestion: assume that we don't think that that the potential uses of Value.Swap justify duplicating or complicating Value.Set. We could add an implementation of Swap based on write side lock, and see if it has users. And based on that we can decide if it deserve to be optimized or not.

[dvyukov]

And what if it does not have users? Or, if it has users, but they use it wrongly?
This is not so about lines of code or optimization, this is much more about interfaces. If we start putting stuff into standard library public interface just to test some hypothesizes, it will grow without a limit with multiple ways of doing the same thing and with lots of ways which provoke bugs.
This should be done the other way around -- show dozens of existing packages in the wild that all duplicate this Swap pattern (which is perfectly implementable without standard library help), then we can consider including it into standard library.

[mlitvin]

This is getting into the realm of arguments that cannot be won. Against my better judgment I'll try to present the counter argument. 1. How many libraries in the wild implemented Value before it was inserted into the standard library? How many independent implementation in the wild of atomic.SwapUintptr have you seen? The sync.atomic package implement atomic operation for 7 types. It implement Load and Store for all of them. It implement Add for all the 5 of them that have a meaningful interpretation of addition. It implement Swap only for 6 of them even though the seventh has a clear and valid semantic (as clear and valid as its store semantic). Looking at it from this point of view its not guarding against feature sprawl, but protecting arbitrary Swiss cheese decision. I'm perfectly aware that there is another point of view: 6 of the types are just exposing primitive CPU capabilities while Value is another beast all together (and its API is also different). But then I argue that it is the job of the standard library to allow developer to ignore the distinction. 2. The "trick" with guarding only the store and not the load with a mutex is a non-trivial trick. It is trivial to implement but not easy to think about. IMHO this is exactly the kind of think that should be in the standard library: It guide developers to write better code than they would have done without it.

…

On Thu, Feb 15, 2018 at 4:26 PM Dmitry Vyukov ***@***.***> wrote: And what if it does not have users? Or, if it has users, but they use it wrongly? This is not so about lines of code or optimization, this is much more about interfaces. If we start putting stuff into standard library public interface just to test some hypothesizes, it will grow without a limit with multiple ways of doing the same thing and with lots of ways which provoke bugs. This should be done the other way around -- show dozens of existing packages in the wild that all duplicate this Swap pattern (which is perfectly implementable without standard library help), then we can consider including it into standard library. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#20164 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGQSfM33pvarmzDzJk_t4JZha_-nO3Dwks5tVD56gaJpZM4NLpWZ> .