I need a crash course explanation of processor concurrency fundamentals, such as the #rustlang core::sync::atomic types and fence function.
I've just introduced a race condition vulnerability into bitvec and I need to eliminate it with as little cost as possible.
-
Show this thread
-
problem: CPU instructions operate on whole elements, but bitvec types operate on bit regions. Two non-overlapping bitvec type instances can reside in the name element. Manipulation of those instances in parallel will thus race.
1 reply 0 retweets 2 likesShow this thread -
should I require that all backing storage uses Atomic types? should I memory-fence all access? I have the capability in the crate to detect partial-element access, so I can fence just that, with a branch overhead.
1 reply 0 retweets 2 likesShow this thread -
Expanding: the race condition can only occur on partially-controlled elements. I can branch to detect this, and only fence on partial control, or I can have no branch, and fence all modification. I don't know which is the better behavior. I guess I could bench it,
2 replies 1 retweet 2 likesShow this thread -
Replying to @myrrlyn
Not sure if useful, but check out AtomicCell (it's just a Cell that implements Send+Sync, has zero space overhead, uses atomic instructions when T fits into AtomicUsize, and falls back to spinlocks otherwise - really good spinlocks with optimistic reads): https://docs.rs/crossbeam-utils/0.6.5/crossbeam_utils/atomic/struct.AtomicCell.html …
1 reply 0 retweets 1 like
Also don't know of a quick crash course :( but if you need learning resources for this kind of stuff, take a look athttps://github.com/crossbeam-rs/rfcs/wiki …
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.