You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// TODO(mknyszek): This isn't the only place we have
// an atomic monotonically increasing counter. It would
// be nice to have an "atomic max" which is just implemented
// as the above on most architectures. Some architectures
// like RISC-V however have native support for an atomic max.
}
This sounds like a useful primitive to have when you need an atomic counter. This is similar to the accepted proposal for And/Or operators
Initially, as the comment suggests, we can use a similar stub implementation using a for loop and atomic Cas, but we should be able to write optimized assembly code per GOARCH.
We can check the machine code for such a routine in C and Go stub. For Risc-V we have AMOMAX and AMOMIN we can use, not sure about other arches.
There is a proposal to add atomic maximum/minimum to libstdc++. Quoting some of the motivations used there:
optimal implementation of lock-free shared data structures - as in the motivating example later in this paper
reductions in data-parallel applications
recording the maximum so far reached in an optimization process, to allow unproductive threads to terminate
collecting statistics, such as the largest item of input encountered by any worker thread.
For runtime/internal/atomic, we would need
Max
Max64
Maxuintptr
Min
Min64
Minuintptr
The proposed apis for sync/atomic would look something like this:
Regarding the race detector, there are no fetch_max/fetch_min functions in tsan so that needs to be implemented as well, there shouldn't be a problem with this and I'm open to submit such changes to llvm upstream if that helps to move forward with this proposal.
Please feel free to share opinions and possible use cases for such a feature.
The text was updated successfully, but these errors were encountered:
Recently I came across this TODO comment in runtime:
go/src/runtime/mgcsweep.go
Lines 67 to 79 in 7241fee
This sounds like a useful primitive to have when you need an atomic counter. This is similar to the accepted proposal for And/Or operators
Initially, as the comment suggests, we can use a similar stub implementation using a for loop and atomic Cas, but we should be able to write optimized assembly code per GOARCH.
We can check the machine code for such a routine in C and Go stub. For Risc-V we have AMOMAX and AMOMIN we can use, not sure about other arches.
There is a proposal to add atomic maximum/minimum to libstdc++. Quoting some of the motivations used there:
For runtime/internal/atomic, we would need
The proposed apis for sync/atomic would look something like this:
Regarding the race detector, there are no fetch_max/fetch_min functions in tsan so that needs to be implemented as well, there shouldn't be a problem with this and I'm open to submit such changes to llvm upstream if that helps to move forward with this proposal.
Please feel free to share opinions and possible use cases for such a feature.
The text was updated successfully, but these errors were encountered: