我尽可能多地搜索谷歌，但我找不到任何好的答案。
localtime_r应该是一个用于获取系统时间的线程安全函数。但是，当使用Valgrind --tool = drd检查我的应用程序时，它会一直告诉我此函数存在数据争用情况。常见的搜索结果对我说谎，还是我只是遗漏了什么？使用互斥锁包围每个localtime_r调用似乎并不高效，特别是如果它首先应该是线程安全的。这是我如何使用它：
timeval handlerTime;
gettimeofday(&handlerTime,NULL);
tm handlerTm;
localtime_r(&handlerTime.tv_sec,&handlerTm);
有什么想法吗？
答案 0 :(得分：1)
如果documentation表示它是可重入（因此线程安全），那么它就是。
如果代码中存在错误（而不是代码）并且函数不是线程安全的，那么你无能为力（除非使用其他函数） ，并且你不能在你的代码中修复这个：函数必须按照记录的方式运行。
但是，我会对valgrind给出的结果小心。这是一个很棒的工具，我经常使用它。但有时，它只是错误。对于像检测竞争条件一样困难的事情，我会更加小心它所说的内容。特别是关于几十年来使用的标准功能。
我的建议是：忽略它。如果您遇到问题并且相信localtime_r()对此负责，请写入相应的邮件列表以报告问题，和/或使用其他功能。
与此同时，你应该没事。
答案 1 :(得分：1)
从联系手册：
ctime_r（），localtime_r（）和 tzset（）函数是MT-Safe in 多线程应用程序，等等 因为没有直接用户定义的功能 修改以下之一 变量：时区，altzone， 日光和tzname。这四个 变量不是MT-Safe访问。 它们由tzset（）修改 以MT-Safe方式运行。该 mktime（），localtime_r（）和ctime_r（） 函数调用tzset（）。
只要您不直接在代码中访问任何这些变量，valgrind似乎可能会报告误报。它是否会为您提供有关它认为竞争条件在函数中存在的位置的更多详细信息？
除非你对valgrind有进一步的佐证，否则我认为在没有额外锁定的情况下继续使用它是安全的。