In general, yes, it's possible to end up with half-written variables -- mutexes (and/or other synchronization primitives) are used to avoid that kind of problem.

Whether you can encounter it in practice depends on the specific programming language, CPU, compiler, and actual instructions involved. Some operations that seem like they should be atomic from the perspective of a high level language are actually implemented as multiple machine code instructions and the thread could be interrupted between them, causing problems, unless steps are deliberately taken to avoid issues with concurrency.

I have minimal experience with Rust, so I'm not sure how bad the footguns you can run into with unsafe are there specifically, but you can definitely blow your leg off in C/C++...

You're probably doing this on a 32bit or 64bit processor. It writes 32bit (or 64) at a time, using one instruction. There is no time in between, where only specific bits are set.

Here is an excellent free book on the subject by the guy that invented RCU: https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.2024.12.27a.pdf

For anyone interested, I did make a second version of the same logic. Even if i kind of had atomic operations in mind i did not know that i was thinking of atomic or what atomic was for that matter. So in a broad sense i assumed raw pointers were atomic. Also worth noting implementing a false Sync for &str seemed to be unnecessary to get it to run in the first example even if i got the impression during construction that it was. Just pretend in the first example "ExemptSyncStringSlice" is just &str if you want to compare them for some reason.

I don't know the overhead of AtomicPtr compared to raw pointers and it is dependent on operating systems that can use an atomic load store (whatever that means.) But this version seems more "correct" at least.

use std::sync::atomic::{AtomicPtr, Ordering};
use std::time::Duration;


fn main()
{
	let pointer: AtomicPtr<&'static str> = AtomicPtr::new(&mut "Hello!");

	let mut value2: &'static str = "Hi!"; // Place outside scope due to lifetime.

	thread::scope(|scope|
	{
		scope.spawn
		(|| {
			for _ in 1..1000
			{
				unsafe { println!("String = {}",  *pointer.load(Ordering::Relaxed)); }
			}
		});

		scope.spawn
		(|| {
			sleep(Duration::from_millis(1));
			pointer.store(&mut value2, Ordering::Relaxed)
		});
	});
}

Thank you all who responded btw.

I would expect unsynchronized access to the same memory to be Undefined Behaviour (and I checked that in C++ it is: https://stackoverflow.com/a/79698067/1122720 and then I also checked that in Rust it also is: https://doc.rust-lang.org/reference/behavior-considered-undefined.html)

Considering that, I wouldn't expect coherent results. In simple cases the compiler may optimise away a lot of code based on the assumption that UB never happens, see also: https://predr.ag/blog/falsehoods-programmers-believe-about-undefined-behavior/

I have written a custom synthesizer for my game engine, with the audio running on its own thread. In this case, I managed to get away without any audible issues.

Same with my evdev event readers, that required their own threads, or else they blocked all other threads. No mutexes.

Your mileage may vary though, and probably with extensive testing I could find hazard cases.