Thanks Jonathon, these are the kinds of warnings I was looking
for.
There are _no_ guarantees of atomicity with shared. Yes, on some
architectures, writing a word size might be atomic, but the
language
guarantees no such thing.
I was looking narrowly at x86, which I *think* such a statement
is safe to say for. But you're absolutely right that I should
probably safeguard against the possibility that something could
go wrong there.
either that or
you have to mess around with core.atomic, which is the kind of
code that is
_very_ easy to screw up, so it's generally advised not to
bother with
core.atomic unless you actually _need_ to.
It will at least ensure sequential consistency, atomic
load/store, and atomic operations (via atomicOp), will it not?
shared really doesn't guarantee anything. It just means that
you can access
that object across threads, which means that you must do all
the work to make
sure that it's protected from being accessed by multiple
threads at the same
time.
Fair enough. It will force the compiler to write to memory
immediately though, rather than keep shared values sitting in
registers, correct?
