mktime和localtime_r能在多线程环境下使用么？
localtime和mktime是用来在时间分量和时间秒数之间进行转换的标准c函数。
在glibc的文档描述中，localtime的实现是使用了一个内部静态缓存来保存结果，所以这是一个不可用于多线程环境的api。glibc提供了一个线程安全版本localtime_r。mktime不存在这个问题。
所以，按照glibc的文档，在多线程环境下可以安全的使用localtime_r和mktime，实际情况并非如此。
mktime和localtime_r在实现上都考虑了时区的转换，而时区的计算要使用全局变量tzname/timezone/daylight。这本质上就是线程不安全的。
参考glibc-2.3.2的源代码（下面的源代码位置都是相对于源码根目录的）
--------- time/localtime.c 和 time/tzset.c
localtime_r中调用了tzset_internal来设置时区，入口参数为always=0，所以理论上只要第一次初次化过了，就不需初始化了。参考下面的代码。
但是由于引入了静态变量is_initialized，在多线程环境下，这种实现代码是有问题的。无法保证并发执行环境下的正确性。
---- (time/tzset.c) -------
/* Interpret the TZ envariable. */
static void
internal_function
tzset_internal (always)
int always;
{
static int is_initialized;
register const char *tz;
register size_t l;
char *tzbuf;
unsigned short int hh, mm, ss;
unsigned short int whichrule;
if (is_initialized && !always)
return;
is_initialized = 1;
...........
}
但是mktime不是这样的，
---- (time/mktime.c) -------
/* Convert *TP to a time_t value. */
time_t
mktime (tp)
struct tm *tp;
{
#ifdef _LIBC
/* POSIX.1 8.1.1 requires that whenever mktime() is called, the
time zone names contained in the external variable `tzname' shall
be set as if the tzset() function had been called. */
__tzset ();
#endif
return __mktime_internal (tp, my_mktime_localtime_r, &localtime_offset);
}
由于_LIBC被定义，所以tzset将每次都被调用，而tzset的代码是这样的
---- (time/tzset.c) -------
void
__tzset (void)
{
__libc_lock_lock (tzset_lock);
tzset_internal (1);
if (!__use_tzfile)
{
/* Set `tzname'. */
__tzname[0] = (char *) tz_rules[0].name;
__tzname[1] = (char *) tz_rules[1].name;
}
__libc_lock_unlock (tzset_lock);
}
tzset_internal将每次都被调用，时区信息将每次都被重写。
需要说明的是，前面的宏__libc_lock_lock在sysdeps/generic/bits/libc-lock.h中定义为：
#define __libc_lock_lock(NAME)
是个空操作，所以它不能起到同步线程的作用。
所以，可以看到，glibc的上述代码实现中，有两个问题：
1、tzset_internal 中使用的static变量is_initialized
（这个我们可以通过在程序中定义一个无用的全局变量，在线程开始工作前，它的初始化中调用一次mktime来克服）
2、mktime每次都要重写全局变量tzname/timezone/daylight
（这个问题，基本上，就没办法解决了）
所以mktime和localtime_r不适合于多线程应用。
解决方案有二：
1、自己实现mktime和localtime_r，但是这样时区的计算是麻烦的，当然也可以不使用时区信息，或者使用固定时区，比如北京时区，这样就简单多了。
2、用pthread的mutex来给mktime和localtime_r加锁，但是这样要使用pthread库，移植性不够好。