index must be align

[marakew]

zedio/zedio/runtime/multi_thread/queue.hpp

Line 341 in 8eff804

uint32_t tail_{0};

atomic (rust and C++) by default has align
but uint32_t has no align
so false sharing will be decrease performance

[marakew]

use align as less from https://en.cppreference.com/w/cpp/atomic/atomic_ref

struct Counters { int a; int b; }; // user-defined trivially-copyable type
alignas(std::atomic_ref<Counters>::required_alignment) Counters counter;
std::atomic_ref<Counters> cnt(counter); // specialization for the user-defined type

[marakew]

but align by cacheline will be better
like from
https://github.com/tokio-rs/tokio/blob/master/tokio/src/util/cacheline.rs

and align for atomic too

[marakew]

boost has align for all fields
i dont known why rust doest align

https://www.boost.org/doc/libs/1_63_0/boost/fiber/detail/context_mpsc_queue.hpp

[marakew]

so strange
tokio improve mpsc align for tokio channel but not for internal queue
tokio-rs/tokio#5830

[8sileus]

Can I simply understand that to solve false-sharing?

[marakew]

original work streal spmc from go
https://github.com/golang/go/blob/4ed358b57efdad9ed710be7f4fc51495a7620ce2/src/runtime/runtime2.go#L668
does not use align
but i dont known how align work for go

but my opinion align must be present
article https://alic.dev/blog/false-sharing

[marakew]

so you can close issues

in my own implementation i will use cache align for indexs and buffer

[8sileus]

so you can close issues

in my own implementation i will use cache align for indexs and buffer

Yes
I'm not very good at this, but I think you're right
I am busy with graduation at the moment, and I will do it when I have time

[marakew]

iam look inside many implementation of spmc queue
some implementation has align, some not
may be it has sense, spmc queue in work steal case, most single produce/single consume queue
so multimple consumer rare consume
but its need make a tests for this

[marakew]

tail_ index can change to atomic
and all drect access to "relaxed" model
atomic_ref remove

this because golang has no memory model like C++ and has no "relaxed" memory model
tokio was not precise while porting from golang

[8sileus]

tail_ index can change to atomic and all drect access to "relaxed" model atomic_ref remove

this because golang has no memory model like C++ and has no "relaxed" memory model tokio was not precise while porting from golang

temporary update
If there is a better plan in the future, I will update it