Very Computer

Hi All,

I'm using pthread(C++) programming in Solaris 9 and find that localtime is
not thread safe. Is it true?

From pstack result, I found 2 process hang for
-----------------  lwp# 1 / thread# 1  --------------------
 febc5dd4 lwp_park (0, 0, 0)
 febc25b4 slow_lock (97030, fe850000, 0, 0, 0, 0) + 58
 fe8bc718 getenv   (fe929e20, 756a0, 0, 0, 0, 0) + 1c
 fe8c6970 getsystemTZ (0, 77838, 0, 0, 0, 0) + 14
 fe8c47d8 ltzset_u (422d0a21, 77f7c, 0, 0, 0, 0) + 14
 fe8c4094 localtime (ffbeb5d4, 9b19c, ffbeb5d4, 0, 0, 0) + 14
....
-----------------  lwp# 5 / thread# 5  --------------------
 febc5dd4 lwp_park (0, 0, 0)
 febc25b4 slow_lock (97030, fe850800, 0, 0, 0, 0) + 58
 fe8bc718 getenv   (fe929e20, 756a0, 0, 0, 0, 0) + 1c
 fe8c6970 getsystemTZ (0, 77838, 0, 0, 0, 0) + 14
 fe8c47d8 ltzset_u (422d0a22, 77f7c, 0, 0, 0, 0) + 14
 fe8c4094 localtime (fda7bf3c, ff16269b, fda7bf3c, 0, 0, fda7bf2c) + 14

Is there solution for this?

Thanks.

Franklin

Quote:> I'm using pthread(C++) programming in Solaris 9 and find that localtime is
> not thread safe. Is it true?

From the NOTES section of the manual page of ctime(3c):

     The return values for  ctime(),  localtime(),  and  gmtime()
     point  to  static  data whose content is overwritten by each
     call.

     [...]

     The asctime(), ctime(), gmtime(), and localtime()  functions
     are unsafe in multithread applications.  The asctime_r() and
     gmtime_r()   functions   are   MT-Safe.    The    ctime_r(),
     localtime_r(),  and  tzset()  functions  are MT-Safe in mul-
     tithread applications, as long as no  user-defined  function
     directly  modifies one of the following variables: timezone,
     altzone, daylight, and tzname.  These four variables are not
     MT-Safe to access. They are modified by the tzset() function
     in an MT-Safe manner.   The   mktime(),  localtime_r(),  and
     ctime_r() functions call tzset().

Quote:> Is there solution for this?

Use localtime_r() instead of localtime().

Andreas.

Notice that the interface for localtime_r is still actually broken
from a true MT standpoint, since from the man page:

 The mktime(), localtime_r(), and ctime_r() functions call tzset().

A truely MT safe implementation would have taken a pointer to
a compiled timezone in addition to clock and struct tm *....; no
need to look out for tzset calls.

- Bart

Quote:> Notice that the interface for localtime_r is still actually broken
> from a true MT standpoint, since from the man page:

>  The mktime(), localtime_r(), and ctime_r() functions call tzset().

> A truely MT safe implementation would have taken a pointer to
> a compiled timezone in addition to clock and struct tm *....; no
> need to look out for tzset calls.

This is correct but it does not seem to be a problem here as long
some variables are not modified. From the manual page ctime(3c):

   The ctime_r(), localtime_r(), and tzset() functions are MT-Safe in
   multithread applications, as long as no user-defined function directly
   modifies one of the following variables: timezone, altzone, daylight,
   and tzname.

(Then, on the other hand, this appears to me like a mine field.
I cannot understand why C or standard C libraries are used at all
for MT stuff).

Andreas.

Quote:> Notice that the interface for localtime_r is still actually broken
> from a true MT standpoint, since from the man page:

>  The mktime(), localtime_r(), and ctime_r() functions call tzset().

> A truely MT safe implementation would have taken a pointer to
> a compiled timezone in addition to clock and struct tm *....; no
> need to look out for tzset calls.

Not to mention the ability to work simultaneously in multiple time zones,
as needed.

Now my real peeve with times isn't programming, it's Calendar Manager. As
it stands, both rpc.cmsd and the clients need to be running the same time
zone.  IMO what it _should've done (to allow worldwide clients of a single
rpc.cmsd to be well supported, i.e. so a worldwide video conference for
example could be scheduled in _someone's_ local time, notwithstanding that
said local time might have daylight savings which in turn might not have
the same rules for start/end that everyone else's did) is have the server
process always run in UTC but always record dates in the local time of the
client creating the entry, and always tell clients the timezone of an
existing entry.  The problem then would be that the timezone rulebase
might not be consistent between client and server...

--

Lasik/PRK theme music:
    "In the Hall of the Mountain King", from "Peer Gynt"

Seems to me that a language that made it safer (but could it ever make
it truly safe?) would force design choices on you, not all of which
were needed simply for correctness.  As a control freak, I think I
disapprove.  As for those that fail to pay attention to details, they
shouldn't be programming anyway, they should doing something a little
lower on the skill scale.

--

Lasik/PRK theme music:
    "In the Hall of the Mountain King", from "Peer Gynt"

You won't catch me arguing with you there...
dtcm & rpc.cmsd are indeed really absurd.

Quote:> Not to mention the ability to work simultaneously in multiple time
zones,
> as needed.

:-) imagine that

Any interest in seeing multiple time zone interfaces?

- Bart

Quote:> Seems to me that a language that made it safer (but could it ever make
> it truly safe?) would force design choices on you, not all of which
> were needed simply for correctness.

Not necessarily as there exist languages that provide a safe
framework that can be left in isolated cases.

Quote:> As a control freak, I think I
> disapprove.  As for those that fail to pay attention to details, they
> shouldn't be programming anyway, they should doing something a little
> lower on the skill scale.

The problem is not to write MT applications. The problem is to verify the
correctness of MT applications that were written by other people. And
this is not just inherently challenging for MT stuff in general but in
particular if C or standard C libraries are used.

Andreas.

Quote:> You won't catch me arguing with you there...
> dtcm & rpc.cmsd are indeed really absurd.

>> Not to mention the ability to work simultaneously in multiple time
> zones,
>> as needed.

>:-) imagine that

> Any interest in seeing multiple time zone interfaces?

Might be chicken-egg situation if no existing code does
that, nor can because no such function already exists.

From what I said about rpc.cmsd, it should be clear that
I can imagine server processes that might have a reason
to be operating in UTC plus a different local time for each
thread potentially; not that I have any plans for writing
such a program myself.

Is there an implementation that takes compiled timezone info
(or otherwise makes timezone a parameter) that anyone knows
of for some other platform (probably LInux or one of the BSDs)?
If there was, and it addressed all the design problems, that
might be something to follow, both because there might be existing
code that uses it, and because even ad hoc standardization is
better than none.

Absent that, the only way I can see that any existing code might
be juggling multiple timezones in one process is by duplicating
a lot of the functionality of the existing functions.

--

Lasik/PRK theme music:
    "In the Hall of the Mountain King", from "Peer Gynt"