多线程问题，过来瞧瞧
一个线程对一个char 字符数组更新数据，主线程会读取这个数组的数据，但是，读之前都会进判空，
比如char g_str[200]={'0'};
线程一
update g_str
主线程
if(!g_str[0])
return;
请问是否有问题？
多线程 公共资源 判空
[解决办法]
没有问题！但是有点浪费！当数据没有发什么变法的时候，就不需要再进行主线程的判断！
所以在线程一应该更新到一个局部变量，全局量来上一次更新的数据！
[解决办法]
共享资源应该加锁，除非你确定读写都是原子操作或不可被打断
[解决办法]
读出来脏数据能正确处理的话那可以不锁
[解决办法]
有可能是读的过程中，正在写数据，读时候判断的长度和内容，读的过程中另一个线程会改写，最好是加锁，这是习惯问题。看看这篇文章吧，http://www.doc88.com/p-330763974969.html
[解决办法]
因为你不知道你的编译器会生成什么样的汇编指令，所以你不能单纯的依赖C++代码，推测线程之间的同步关系。
编译器不知道你在多个线程之间有共享数据，它不知道你在一个线程中写的数据，另外一个线程会使用。写的线程可能只是把数据写到寄存器或者缓存中，而不产生写入内存的指令；读的线程也可能只是从寄存器或者缓存中读取，而不产生读取内存的指令。
不是说读写本身会导致未定义行为，是你使用这些数据时，特别是依赖于这些数据有效性的代码，可能导致未定义行为。多核CPU下的特殊性是多个CPU同时执行的指令（每个指令分为数个步骤）可能涉及同一个内存地址。如果两个线程同时写，那么最终结果什么值都有可能。仅分别读写，读到的数据可能是改之前的也可能是改之后的。
[解决办法]
加锁吧, 锁本身损耗不大, 竞争锁引起的等待代价比较高, 看大约有多少时间多少机会是会引发竞争.
[解决办法]
看业务逻辑，如果主线程有其他活可干，循环检测是可以简单不上锁，确定要进一步读取再加锁。不过你直接return，看不出是啥逻辑...
[解决办法]
其实还是需要结合实际业务需求的！如果不想出现不必要的bug，还是建议加上锁吧！
安全可靠点！
