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