Add RwLock and concurrency enabled LinearMemory

[wucke13]

Pull Request Overview

Adds:

• RwSpinLock, a spinning, writer preferring read-write lock implementation
• LinearMemory, a linear memory implementation that enable shared concurrent access

Testing Strategy

This pull request was tested by its including tests

TODO or Help

This pull request still needs a keen eye on the use of ordering for the atomic operations in the RwSpinLock implementation.

Formatting

• Ran cargo fmt
• Ran cargo check
• Ran cargo build
• Ran cargo doc
• Ran nix fmt

Github Issue

This pull request continues the ideas laid out in #135

[codecov]

Codecov Report

Attention: Patch coverage is 94.11765% with 31 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/execution/linear_memory.rs	96.22%	8 Missing and 6 partials ⚠️
src/execution/interpreter_loop.rs	86.66%	0 Missing and 10 partials ⚠️
src/core/rw_spinlock.rs	91.17%	6 Missing ⚠️
src/execution/mod.rs	75.00%	0 Missing and 1 partial ⚠️

Files with missing lines	Coverage Δ
src/core/little_endian.rs	100.00% <100.00%> (ø)
src/execution/store.rs	86.66% <100.00%> (-0.84%)	⬇️
src/lib.rs	27.17% <ø> (ø)
src/execution/mod.rs	93.48% <75.00%> (-0.06%)	⬇️
src/core/rw_spinlock.rs	91.17% <91.17%> (ø)
src/execution/interpreter_loop.rs	99.08% <86.66%> (+<0.01%)	⬆️
src/execution/linear_memory.rs	96.22% <96.22%> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[eva-cosma]

The code looks good overall, but I would like a soundness check w/r/t to atomic ordering. I'm not super familiar with them, but I know of the importance of getting them right. Perhaps we can make this a topic for tomorrow's meeting

Also, for the spinlock, while I have no gripes of setting u32::MAX/2 as a soft-maximum and having u32::MAX as a "writer present flag", it isn't really that rust-y. A rogue +1 with the u32::MAX set can result in an underflow/panic. If we believe we are not going to touch this code in the near future, we can leave this as is, since it looks like a correct implementation. If not, having an inline function to turn the AtomicU32 (after get) into an enum variant that we then check, or the other way around (before set) can reduce the chance of a logic bug appearing.

[wucke13]

Mara Bos describes a mechanism to favour writers without having wainting_writers atomic. Instead, readers always increment the lock by 2, and waiting writers by one. New reader that see an uneven state wait until the state becomes even again.

Further information: https://marabos.nl/atomics/building-locks.html#avoiding-writer-starvation

[wucke13]

@george-cosma @cemonem I tried to apply your feedback, fix the bugs, improve the locking a bit further, now with ordering completely identical to the mara bos book. I also extended the documentation. From my point of view, this PR is good. Please have a look if you find any more gotchas 😄