There is lots of good advice in this thread. I would like to focus on your comment about race conditions. It's very good that you have identified this weakness

There is lots of good advice in this thread. I would like to focus on your comment about race conditions. It's very good that you have identified this weakness in your code. Writing concurrent code is hard, but it's also valuable experience because there is no room for shortcuts. If you don't do it right, your code will fail eventually. Therefore writing concurrent code, identifying bugs, and fixing them will train you to think rigorously about your code. Diagnosing bugs often comes down an exploration of every possible sequence of events, trying to identify the pattern of sequences that triggers the bug, and figuring out how to fix it. In single-threaded code the debugger can make this task easy, but attaching a debugger (or even building in debug mode) often makes concurrency bugs go away, so you are forced to solve the problem in your head by analyzing the system. This experience is like strength training for programmers. I would suggest putting extra effort in the concurrent parts of your code, really try to make them correct. In the end, the practice will improve the quality of your non-concurrent code too.