ConcurrentStore.inner is now Arc<RwLock<CubeStore>>: all read paths take the
read side, all mutations + checkpoint take the write side. Readers no longer
exclude each other and overlap an active writer (verified by
concurrent_reads_dont_block_on_writer + cube-bench Task 4 section). WAL,
checkpoint, and coordinate encoding are untouched, so durability/replay is
unchanged (.check green).
Honest finding recorded in docs/task4-reader-writer-sharding.md: on this 8-core
host std RwLock removes reader-vs-reader exclusion (correct) but shows no
wall-clock speedup for short reads (cache-line bounce on one shared lock). Real
read-throughput scaling would need sharded/lock-free storage, left as a
follow-up decision rather than invented.
- cube-bench crate: real-code-path throughput/latency over cubestore,
cubecrypt (aes/gcm/chacha/xts), cubecode VM, and cubesys Session.
Every section asserts correctness before timing. Wired into ./check
as an opt-in 'bench' stage.
- cubesys Session: per-command latency histogram + per-C-namespace record
counts, exposed via a new 'stats' command over the live socket.
- Deployed rebuilt cube-server to /home/luulu/.cubelinux/bin and
restarted the system cube.service; verified stats live.
CUBELinux-2