The whole idea "it is not required to be safe" is wrong in case of multithreading.
When someone says "it is not required to be safe" it simply means "this call will never be done from more than one thread" or even "it cannot be called by more than one thread, so, if someone needs thread safety, the call should be wrapped in appropriate lock or mutex statement".
So, now you know how issues are related. What should you do in the multithreading situation? In most cases, you need to guard the access to some object using mutual exclusion. On Windows, if you do it in the same process, it can be lightweight version of it called
CriticalSection
. If you need to access to the same object from different processes, this is more complex: you will need IPC, and, for mutual exclusion, you will need a named mutex. Please see:
http://en.wikipedia.org/wiki/Mutual_exclusion[
^],
http://en.wikipedia.org/wiki/Inter-process_communication[
^].
I only mentioned basic approaches. At least this is how you can guarantee thread safety.
Don't even play with the idea of having threads and not thread-safety. If cannot work. Or, much worse, it may seemingly work, but for a while, which is a great danger. Don't even think about it.
On top of thread safety, you can consider more delicate design issue related to performance. As people say,
best synchronization is no synchronization. That said, you need to provide 100% of thread safety but make it as fine-grain as possible. Also, it depends very much on how much you read the state of the object and how much you modify it. More complex thread synchronization objects can greatly improve performance in the situation where threads often read the state of the object but its modification is seldom.
It is important not to over-synchronize things. In this forum, I faced some "solution" where people synchronized the thread so much that they actually could only execute one at a time. Again, make synchronization as fine-grain as possible, yet 100% guaranteed. Some education and experience required.
—SA