Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Atomic maps #17043

Closed
kirillDanshin opened this issue Sep 9, 2016 · 6 comments
Closed

Proposal: Atomic maps #17043

kirillDanshin opened this issue Sep 9, 2016 · 6 comments

Comments

@kirillDanshin
Copy link

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

1.6.2, 1.7.0

What operating system and processor architecture are you using (go env)?

some i386, some amd64. ubuntu 16.04, centos 7, fedora 24.

What did you do?

Writing an embedded key-value storage.

What did you expect to see?

Built-in thread-safe maps or sync/atomic methods for concurrent maps access without blocking whole map.

What did you see instead?

No thread-safe maps and no sync/atomic methods for concurrent maps access.

Some kind of dup #1682.
Also, I know about this note. If it impossible to built in thread-safe maps without performance issues, then we can built-in some methods in sync/atomic.

@bradfitz
Copy link
Contributor

bradfitz commented Sep 9, 2016

As you've found, this has been considered, rejected, re-proposed, rejected, etc in the past.

It's not going to be changing at this point.

Note that it's perfectly safe to access maps concurrently from multiple goroutines, as long as all the goroutines are reading. Only once you need to mutate something do you need to grab an exclusive lock. If you need to concurrently update items, you can make your map values be pointers, and have mutexes or atomics inside your values.

@bradfitz bradfitz closed this as completed Sep 9, 2016
@kirillDanshin
Copy link
Author

But #1682 says only about built-in thread-safe maps, not about sync/atomic upgrade.
And sync/atomic upgrade will be useful and save performance on current level.

@bradfitz
Copy link
Contributor

bradfitz commented Sep 9, 2016

Then #17043 is about saying no to sync/atomic also.

@kirillDanshin
Copy link
Author

Ok, if it impossible to do in this package, is it possible to do it in any standard Go package?

@bradfitz
Copy link
Contributor

bradfitz commented Sep 9, 2016

We will not be supporting concurrent write+write or read+write map updates in the standard library, in any package.

We will not support them in our house,
We will not support them with your mouse.
We will not support them here or there,
We will not support them anywhere.
We kinda support them, in an atomic.Value box,
We will not support them in Firefox.
We will not support them in a car, ... (please, no unsafe in automotive systems..)

@AlekSi
Copy link
Contributor

AlekSi commented Sep 4, 2017

Yet you support them in Go 1.9. 😂

@golang golang locked and limited conversation to collaborators Sep 4, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants