Question: So I'm writing this neat little program to teach myself threading, I'm using boost::thread and C++ to do so.

I need the main thread to communicate with the worker thread, and to do so I have been using global variables. It is working as expected, but I can't help but feel a bit uneasy. 

What if the the worker thread tries write to a global variable at the same time as the main thread is reading the value. Is this bad, dangerous, or hopefully taken into account behind the scenes??

Answer: 
§1.10 [intro.multithread] (quoting N4140):

> 
> 6 Two expression evaluations *conflict* if one of them modifies a
>  memory location (1.7) and the other one accesses or modifies the same
>  memory location.
> 
> 
> 23 Two actions are *potentially concurrent* if
> 
> 
> * they are performed by different threads, or
> * they are unsequenced, and at least one is performed by a signal handler.
> 
> 
> The execution of a program contains a *data race* if it contains two
>  potentially concurrent conflicting actions, at least one of which is
>  not atomic, and neither happens before the other, except for the
>  special case for signal handlers described below. Any such data race
>  results in undefined behavior.
> 
> 
> 

*Purely* concurrent reads do not conflict, and so is safe.

If at least one of the threads write to a memory location, and another reads from that location, then they conflict and are potentially concurrent. The result is a data race, and hence undefined behavior, unless appropriate synchronization is used, either by using atomic operations for all reads and writes, or by using synchronization primitives to establish a *happens before* relationship between the read and the write.
Concurrent writes are not safe. Concurrent read and write are always safe (assuming atomic writes), but you never know whether you've read the value before or after write.

Main thread behaves just the same as spawned threads, there's no difference at all.

So, for concurrent write you'll need mutexes.