-
Notifications
You must be signed in to change notification settings - Fork 17.5k
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: runtime: maps: add optional concurrency #63513
Comments
Have you seen https://pkg.go.dev/sync#Map and #47657? |
Also, since this looks like a proposal to change the |
yes, of course :)
|
My goal was doing it w/o changing the language itself, just the map piece of the standard library. |
Duplicate of #1682 |
Maps are defined in the spec, along with all the operations that can be done on them: https://go.dev/ref/spec#Map_types |
The current map implementation currently does not support concurrency - just detects concurrent calls and panics. This is very unfortunate for a language desinged for parrallel computing. Concurrent code cannot use maps directly - it needs to do an own implementation, at least by some wrapper. This drastically devalues the whole existance of the builtin map type. Thefore builtin maps should support concurrency.
Proposal: add rwlock to hmap
Simple and straightforward implementation can just take the lock on the entry of the (user-facing) functions (mapaccess et al). A more sophisticated one can do it on indivual pieces (eg per bucket), eg. skipping if just an existing entry is updated, and take the hmap lock only if necessary.
Performance & backwards compat:
Locking has some (little) performance impact. It would mostly impact concurrent reads, since concurrent writes are currently forbidden anyways.
If this really is a concern, we can add a global bit to enable locking - if unset, the locking is skipped entirely (checking a single bit shouldn't introduce any measurable penalty). Any package that wants it, just sets this bit - applications w/o such packages wont have locking at all, thus no performance impact for existing code.
This global bit could be set eg by some (inlinable) runtime.MapsEnableLocking().
The text was updated successfully, but these errors were encountered: