c - 为什么gmtime_r调用__tz_convert来获取全局锁？

我很惊讶地看到gmtime公司真的在给tz打电话我想有localtime和gmtime的原因是前者进行tz转换，而后者不需要看起来gmtime调用了z-convert，然后它继续并抓住了z的全局锁（这甚至不需要对吧？）
我是不是丢了什么东西？
如何在多线程应用程序中高效转换epoch->struct tm？

(gdb) where
#0  0x00007fffee255eec in __lll_lock_wait_private () from /lib64/libc.so.6
#1  0x00007fffee2007bc in _L_lock_2546 () from /lib64/libc.so.6
#2  0x00007fffee2005f7 in __tz_convert () from /lib64/libc.so.6
#3  0x000000000041c63f in DateTimeEx (dt=..., this=0x7fffca551900) at /var/lib/jenkins/workspace/hfalgo_src_hotfix_1.69.1-T6J4HNFQDMYVEKV4MEGVD6UCCPG7KHWQDOSVYBUDROFXZA6YINSA/hfalgo_src/./core/Time.h:81

最佳答案

glibc可以处理包含闰秒信息的时区数据库文件，并且gmtime和gmtime_r将这些闰秒考虑在内（例如，Debiantzdata包在/usr/share/zoneinfo/right目录中提供了这样的时区文件。）这就是glibc实现读取时区数据库并执行与之相关的锁定的原因。
我不知道有谁真正使用闰秒功能POSIX当前要求count since epoch不考虑任何闰秒，因此使用闰秒数据文件会导致函数的不一致行为，如gmtime。
但是，我希望一些不可移植的软件依赖于调用gmtime或gmtime_r执行隐式的tzset调用，从而初始化tzname和其他全局变量这是在当前实现中消除锁定的更大障碍（有人甚至为此发了一个悬赏，但100美元的价格与修复此问题所需的努力完全不成比例。）
如果您今天需要避免锁，您需要查找gmtime算法（对于这些问题，日历计算是一个有趣的参考）并自己实现它。