A few questions about safe concurrent programming assumptions

[Nicholas Smith]

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?