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: 
The simple answer is yes. Once variables are starting to be shared amongs multiple threads for both reading and writing you will need some kind of protection.
There are different flavours to achieve this :
Semaphores,
locks,
mutex,
events,
critical section
message queues.
Especially when your globals are references things can become ugly.
Suppose you have global list of objects in a consumers / producers scenario with multiple consumers, the producer instantiates objects, the consumer takes them, does something with them and finally disposes them, without protection of some sort this leads to terrible problems.
There is a lot of specialised literature about this topic and there are dedicated college courses about this topic, and well known problems that are being given to students. For instance the dining philosefers problem, howto make a readerswritersemaphore without starvation, ... .
Interesting book : the little book about semaphores.
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.