[ETA: I connected with some hardware architecture experts, who reassured me that this wasn't a problem.]
Suppose I have two threads, that are updating the contents of a
Vec<u8>
. If the two threads update areas that do not share
words in common, then they don't need any synchronization. But
let's say that thread #1 updates &v[0..5]
and thread #2 updates
&v[5..8]` of an eight-byte vector.
I remember from back when I worked on the JVM, that there were
important constraints on this sort of thing, and in short, you had to
act as if these threads were updating the same word, and not
non-overlapping sequences of bytes.
I'm not a Rust expert, and certainly not even an LLVM newbie. So I
don't know where to start looking, to learn whether this sort of thing
is a problem or not, but geez, at least from what I've seen of the way
Rust allows me to cut apart a slice into two subslices basically at
any point, it doesn't appear that Rust makes any provision for this.
I should add that it's not a big deal: as long as you deal with stuff
at word-size (64-bit quantiities) and up, it's simply a non-problem.
But I do wonder about whether this problem actually occurs for smaller
quantities.
It would seem somewhat straightforward to solve in the internals of
copy_from_slice
-- just do a little address-arithmetic at the
endpoints of the destination slice to figure out if the ends are
partial words, and if so, then use compare-and-swap to move the data
there.
Lest this seem completely wacky, I guess I should explain how this
came up. I've written a fast "concat slices" function, that uses
rayon
to parallelize copying from source slices into subslices of a
destination vector. I'm only using it on word-size-and-larger
element-types, but it occurred to me that maybe one ought to check
that it would work correctly on smaller element-types.
Hence my question.
ETA: of course, my suggestion for what to do in copy_from_slice
only
works for that -- the more general issue of when two adjacent &[u8]
slices are not going to interfere if they're being modified by different
threads seems .... complicated at least.