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库，移植性不够好。