proposal: sync: support for sharded values
Per-CPU sharded values are a useful and common way to reduce contention on shared write-mostly values. However, this technique is currently difficult or impossible to use in Go (though there have been attempts, such as @jonhoo's https://github.com/jonhoo/drwmutex and @bcmills' https://go-review.googlesource.com/#/c/35676/). We propose providing an API for creating and working with sharded values. Sharding would be encapsulated in a type, say `sync.Sharded`, that would have `Get() interface{}`, `Put(interface{})`, and `Do(func(interface{}))` methods. `Get` and `Put` would always have to be paired to make `Do` possible. (This is actually the same API that was proposed in https://github.com/golang/go/issues/8281#issuecomment-66096418 and rejected, but perhaps we have a better understanding of the issues now.) This idea came out of off-and-on discussions between at least @rsc, @hyangah, @RLH, @bcmills, @Sajmani, and myself. This is a counter-proposal to various proposals to expose the current thread/P ID as a way to implement sharded values (#8281, #18590). These have been turned down as exposing low-level implementation details, tying Go to an API that may be inappropriate or difficult to support in the future, being difficult to use correctly (since the ID may change at any time), being difficult to specify, and as being broadly susceptible to abuse. There are several dimensions to the design of such an API. `Get` and `Put` can be blocking or non-blocking: * With non-block
Posted by aclements on Jan 26, 2017, 6:44 PM
Tags
Related issues
- [BUG] Cowork (Windows): all Plan9 shares fail with "Plan9 mount failed: invalid argument" after Windows update KB5124008 (26200.9445) — uninstalling the KB fixe
- Feature Request: Auto-resume CLI session when usage limit resets
- Please deobfuscate the Python
- [Bug] MLX version of Gemma 4 26B fails to load: "Model type gemma4 not supported" (macOS)
- # 233 Developers Discussed Abandoning the Office Add-in Platform — An Open Letter on the Office.js Stability, Security & Trust Crisis
- [FEATURE] Allow users to configure which shell the Bash tool uses or inherit initial shell
Raise real-world problems, find people facing the same issue, and discuss solutions.4,500 issues0 comments
reliability (Software)
[BUG] Cowork (Windows): all Plan9 shares fail with "Plan9 mount failed: invalid argument" after Windows update KB5124008 (26200.9445) — uninstalling the KB fixe
Feature Request: Auto-resume CLI session when usage limit resets
Please deobfuscate the Python
[Bug] MLX version of Gemma 4 26B fails to load: "Model type gemma4 not supported" (macOS)
# 233 Developers Discussed Abandoning the Office Add-in Platform — An Open Letter on the Office.js Stability, Security & Trust Crisis
[FEATURE] Allow users to configure which shell the Bash tool uses or inherit initial shell
Admin Materials and Surfaces
AMD Support
proposal: sync: support for sharded values
Per-CPU sharded values are a useful and common way to reduce contention on shared write-mostly values. However, this technique is currently difficult or impossible to use in Go (though there have been attempts, such as @jonhoo's https://github.com/jonhoo/drwmutex and @bcmills' https://go-review.googlesource.com/#/c/35676/). We propose providing an API for creating and working with sharded values. Sharding would be encapsulated in a type, say `sync.Sharded`, that would have `Get() interface{}`, `Put(interface{})`, and `Do(func(interface{}))` methods. `Get` and `Put` would always have to be paired to make `Do` possible. (This is actually the same API that was proposed in https://github.com/golang/go/issues/8281#issuecomment-66096418 and rejected, but perhaps we have a better understanding of the issues now.) This idea came out of off-and-on discussions between at least @rsc, @hyangah, @RLH, @bcmills, @Sajmani, and myself. This is a counter-proposal to various proposals to expose the current thread/P ID as a way to implement sharded values (#8281, #18590). These have been turned down as exposing low-level implementation details, tying Go to an API that may be inappropriate or difficult to support in the future, being difficult to use correctly (since the ID may change at any time), being difficult to specify, and as being broadly susceptible to abuse. There are several dimensions to the design of such an API. `Get` and `Put` can be blocking or non-blocking: * With non-block
Comments (0)
No comments yet. Start the discussion.