Multithreaded unsafe access to a `Vec`

youre at risk that a write (e.g. push) causes a memory reallocation, in which case your reads could dangle

"Some" kind of synchronization is necessary for the hardware (and language-level UB too), otherwise there are several ways it goes wrong that are worse than what you describe.

Can the Vec become longer/shorter, or are you just changing existing u8 to other values? Some specific access pattern, size, frequency, ...?

Sounds like you want atomics. And if the size is known and fixed, maybe an array.

The solution will be very different if the data can grow or shrink over its lifetime, versus remaining a fixed size. I don’t think anything will get you out of using a lock if the size can change.

You could consider something like https://docs.rs/left-right/latest/left_right/

Not sure if that is highly used, but anyway the oversimplified idea is that it would have 2 vectors. The reader would read from one and the writer would mutate the other and safely sync the versions when the reader isn’t reading.

It is never safe to write while read as you will have in the best case stale data in one thread and not the other (if in cache) and the worst case garbled values because only half of one of your entries was committed to main ram. You need some sync. Could be an array of atomics, could be a mutex or rwlock, there are also crates for multi threaded collections that are optimized for large amounts of concurrency.

It depends. If your threads operate with the Vec through shared ref, then you just can use Vec<AtomicU8>. Judging by the statement that it's ok to read during updates, consistency is not a requirement, so you can use relaxed ordering. Be advised, though, that memory ordering is quite a non-trivial topic, so you may want to enforce some additional guarantees.

In case you want to do mutating operations on Vec itself (mainly operations that can change its size), there is really no other way to use either a lock or some alternative data structure. Mutating Vec itself will lead to use-after-free because of storage reallocation.

Use an array or slice of AtomicU8s, and share that between the threads, if your byte vector doesn't grow. Otherwise, you probably should use Mutex or Rwlock. You might also have some luck searching crates.io for crates providing safe implementations of data structures made for your exact use case (There are none that I know of).

Edit: (after looking at some of the other comments)

Never, ever, share any data that some thread has mutable (in the Rust sense i. e. exclusive) access to with another thread without any kind of synchronisation mechanism.

It's not as simple as "Oh, but I can just pass in a pointer and read from it. I don't care if the data is partially written". Memory is complicated, and the compiler and your CPU, who, theoretically, have full awareness of it's intricacies, may do anything to optimise your code, without some way to restrict them, such as the things the compiler suggested to you.

For example, that pointer you pass in might not point to where you think it does. Those writes you perform might each result in several writes, in several disjoint locations, in different kinds of memory, or none at all. What you're trying to do results in immediate undefined behavior (please read up a bit more deeply on what that means), will not result in anything useful, only completely random problems, anywhere in your program, when you least expect it, that are way worse than just "partially updated values".

look into using a lock free ring buffer

For mutating the current values while another thread is reading it, you can just use a Vec<AtomicU8>.

For adding new values, you can use something like triple buffer or use arc_swap and copy and swap whenever you need to reallocate.

For the latter method, you could make your own Vec(wrapped in an Arc) with an AtomicUsize length that the writer bumps when pushing new elements. When you need to reallocate, the writer allocates a new Arc<CustomVec>, copies the elements over, and swaps the old Arc<CustomVec> with the newly created one. The reader will deallocate the old one if it's currently holding onto it.

Sharing access to an actual Veclike this is never okay, because the writer can trigger reallocation.

But can you just use something like &Box<[A tomicU8]>? Then you can read and write via shared references.

Use Vec<AtomicU8>. Relaxed reads and writes compile down to completely ordinary reads and writes in machine code, so there's no atomic overhead from that.

what you want is a channel

std mpsc channel docs

If you really want to have no synchronization at all for performance reasons, I recommend first not using Vec and instead using something like a Box<[u8]>, and second whatever unsafe code you will have to write, test it with miri.

You might think your unsafe code is sound, I come from a C background and was sure my code manually using pointers had no issues and worked properly, yet when I ran my code with miri it raised some peculiar issues (what in the name of fuck is a "stacked borrow"?) that could (wasn't, but could) result in undefined behavior.

If you're guaranteed not to be reading and writing the same element of the vector simultaneously, vec.as_mut_ptr() returns a pointer to the first element and then unsafe{ *ptr.offset(i) } for reads and unsafe{ *ptr.offset(i) = val } for writes. Don't access the vec in any other way while you are storing a pointer returned by that operation and you won't violate aliasing rules. Do test with miri.

If not, use Vec<AtomicU8> or use synchronization. A unsynchronized read through a ptr is a promise to the compiler that nothing is writing to that piece of memory, not a way to get an arbitrary value back. The compiler will take that promise and rely on it in performing optimizations that will make your program not do at all what you think it does.

The problem here is having a non exclusive mut reference to the same Vec, which is undefined behavior. The limitation itself is easy to overcome by using pointers you cast to a (mut) reference as needed, but be really mindful of undefined behavior.

In case you do not append elements to the vector you can use AtomicU8 with Ordering::Relaxed instead of u8 as the vector element. On arm for sure loads/stores to these would be compiled to the same instructions as the regular loads/stores and you avoid the locking overhead

&[AtomicU8] and Ordering::Relaxed accesses. A non-atomic read that races a non-atomic write is just undefined behavior. Most likely this will just compile to a simple read without any extra memory synchronization, but it prevents things like spuriously duplicated reads causing issues.

Could you shard the vector and use individual mutexes so that the whole vector isn't ever locked by a reader or writer at any given moment?

Here's your footgun:

Get a raw pointer to the vector:

let vec_ptr: *mut Vec<u8> = &mut vec;

Pass that to your threads, and then use unsafe to turn it back into a reference.

let vec = unsafe { &mut *vec_ptr };
vec[i] = i as u8;

// or

let vec = unsafe { &*vec_ptr };
println!("{:?}", vec);

Have fun.

For a more serious answer, I'd consider u/bskceuk's suggestion, using something like this: https://lib.rs/crates/left-right

Claiming that it doesn’t matter if the reading thread operates at the same time as the writing thread is demonstrating either a misunderstanding of what that means, or that your reading thread is doing nothing with the data and probably shouldn’t even exist.

Please note that you cannot do this at all with types where not every possible bit combination is valid (like bool, char or str), or you will have UB which can lead to crashes, code not running that should be, code running which should not be. The Compiler doing optimisations which are completely broken. As soon as you encounter UB you might as well randomise all instructions of your program.

Even if that's the case you will still get corrupted data. Before doing any of this I highly recommend reading the nomicon, even though it isn't up-to-date

Generally: before using unsafe always ask yourself (and potentially others): is there any way I can solve this problem without unsafe.

Oh and some example what undefined behaviour means (I'm using C here, but the same would apply to rust. The code example would just be more complex):

int a;
if (a == a) {
    puts("This code will likely never run and is in fact probably optimised away");
}