-
-
Notifications
You must be signed in to change notification settings - Fork 1
Use barrier-less and lock-less locks where possible #3
Copy link
Copy link
Open
Labels
domain: RustInvolves Rust code.Involves Rust code.priority: somedayIf you need this, please let me know!If you need this, please let me know!state: approvedApproved to proceed.Approved to proceed.type: fixIterations on existing features or infrastructureIterations on existing features or infrastructurework: emergentThe goal isn't known, but a plan exists.The goal isn't known, but a plan exists.
Description
Activity
Metadata
Metadata
Assignees
Labels
domain: RustInvolves Rust code.Involves Rust code.priority: somedayIf you need this, please let me know!If you need this, please let me know!state: approvedApproved to proceed.Approved to proceed.type: fixIterations on existing features or infrastructureIterations on existing features or infrastructurework: emergentThe goal isn't known, but a plan exists.The goal isn't known, but a plan exists.
Projects
- StatusShow more project fieldsReady
Is your feature request related to a problem? Please describe.
The value storage in signals themselves generally doesn't need memory barriers (and in the case of ZSTs, the lock/atomic could be a ZST itself).
Describe the solution you'd like
Rather than using
RwLocks, a slimmer atomic container with (largely?)Relaxedordering could be used.Describe alternatives you've considered
This may be partially covered by #2.
Additional context
I had implemented lock/barrier-skips manually on access before, but that was too error-prone.
Signal propagation does have to introduce some memory barriers for correctness, so that read values are always fresh.