This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++11 status.
Section: 29 [numerics] Status: C++11 Submitter: Lawrence Crowl Opened: 2008-06-23 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [numerics].
View all issues with C++11 status.
Discussion:
There are a number of functions that affect the floating point state. These function need to be thread-safe, but I'm unsure of the right approach in the standard, as we inherit them from C.
[ San Francisco: ]
Nick: I think we already say that these functions do not introduce data races; see 17.6.5.6/20
Pete: there's more to it than not introducing data races; are these states maintained per thread?
Howard: 21.5/14 says that strtok and strerror are not required to avoid data races, and 20.9/2 says the same about asctime, gmtime, ctime, and gmtime.
Nick: POSIX has a list of not-safe functions. All other functions are implicitly thread safe.
Lawrence is to form a group between meetings to attack this issue. Nick and Tom volunteered to work with Lawrence.
Move to Open.
[ Post Summit: ]
Hans: Sane oses seem ok. Sensible thing is implementable and makes sense.
Nick: Default wording seems to cover this? Hole in POSIX, these functions need to be added to list of thread-unsafe functions.
Lawrence: Not sufficient, not "thread-safe" per our definition, but think of state as a thread-local variable. Need something like "these functions only affect state in the current thread."
Hans: Suggest the following wording: "The floating point environment is maintained per-thread."
Walter: Any other examples of state being thread safe that are not already covered elsewhere?
Have thread unsafe functions paper which needs to be updated. Should just fold in 29.3 [cfenv] functions.
Recommend Open. Lawrence instead suggests leaving it open until we have suitable wording that may or may not include the thread local commentary.
[ 2009-09-23 Hans provided wording. ]
If I understand the history correctly, Nick, as the Posix liaison, should probably get a veto on this, since I think it came from Posix (?) via WG14 and should probably really be addressed there (?). But I think we are basically in agreement that there is no other sane way to do this, and hence we don't have to worry too much about stepping on toes. As far as I can tell, this same issue also exists in the latest Posix standard (?).
[ 2009-10 Santa Cruz: ]
Moved to Ready.
Proposed resolution:
Add at the end of 29.3.1 [cfenv.syn]:
2 The header defines all functions, types, and macros the same as C99 7.6.
A separate floating point environment shall be maintained for each thread. Each function accesses the environment corresponding to its calling thread.