[jira] [Commented] (STDCXX-853) [Sun C++ 5.9/Solaris 10/SPARC] assertions in atomic_xchg on __rw_atomic_exchange(short, short)

2012-09-23 Thread Liviu Nicoara (JIRA) 

[ 
https://issues.apache.org/jira/browse/STDCXX-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461443#comment-13461443
 ] 

Liviu Nicoara commented on STDCXX-853:
--

Narrowed it down to aggressive optimization, fixed in r1388733.

 [Sun C++ 5.9/Solaris 10/SPARC] assertions in atomic_xchg on 
 __rw_atomic_exchange(short, short)
 ---

 Key: STDCXX-853
 URL: https://issues.apache.org/jira/browse/STDCXX-853
 Project: C++ Standard Library
  Issue Type: Bug
  Components: Tests
Affects Versions: 4.2.1
 Environment: Sun C++ 5.9/Solaris 10/SPARC
Reporter: Martin Sebor
Priority: Minor
 Fix For: 4.2.2

   Original Estimate: 2h
  Remaining Estimate: 2h

 When compiled with Sun C++ 5.9 (but not prior versions) in 12{d,D,s,S} mode 
 on Solaris/SPARC (but not AMD64) the 
 [{{atomic_xchg.cpp}}|http://svn.apache.org/repos/asf/stdcxx/trunk/tests/support/atomic_xchg.cpp]
  test consistently fails the same two assertions while exercising the 
 {{\_\_rw_atomic_exchange (short, short)}} overload. The test passes all 
 assertions when compiled with gcc 4.1 on the same system.
 {noformat}
 CC -c -mt -I$TOPDIR//include -I/build/sebor/stdcxx-suncc-5.9_j1-12d/include 
 -I$TOPDIR//tests/include  -library=%none -O  -m32 +w -errtags -erroff=hidef   
 $TOPDIR//tests/support/atomic_xchg.cpp
 CC atomic_xchg.o -o atomic_xchg -L/build/sebor/stdcxx-suncc-5.9_j1-12d/rwtest 
 -lrwtest12d -library=%none  -mt  -m32 
 -L/build/sebor/stdcxx-suncc-5.9_j1-12d/lib  
 -R/build/sebor/stdcxx-suncc-5.9_j1-12d/lib:/build/sebor/stdcxx-suncc-5.9_j1-12d/rwtest
  -lstd12d  -lm 
 tests$ 
 tests$ 
 tests$ ./atomic_xchg -q
 thread 0 starting
 thread 1 starting
 thread 2 starting
 thread 3 starting
 thread 0 performed 2173644 exchanges in 1125068 iterations (93% increments)
 thread 1 performed 3122578 exchanges in 2074002 iterations (50% increments)
 thread 2 performed 3722299 exchanges in 2673723 iterations (39% increments)
 thread 3 performed 2141239 exchanges in 1092663 iterations (95% increments)
 thread 0 starting
 thread 1 starting
 thread 2 starting
 thread 3 starting
 thread 0 performed 3107666 exchanges in 2059090 iterations (50% increments)
 thread 1 performed 2624636 exchanges in 1576060 iterations (66% increments)
 thread 2 performed 3256545 exchanges in 2207969 iterations (47% increments)
 thread 3 performed 2539901 exchanges in 1491325 iterations (70% increments)
 thread 0 starting
 thread 2 starting
 thread 1 starting
 thread 3 starting
 thread 0 performed 2235989 exchanges in 1187413 iterations (88% increments)
 thread 1 performed 2600206 exchanges in 1551630 iterations (67% increments)
 thread 2 performed 4103850 exchanges in 3055274 iterations (34% increments)
 thread 3 performed 4124742 exchanges in 3076166 iterations (34% increments)
 thread 0 starting
 thread 1 starting
 thread 3 starting
 thread 2 starting
 thread 0 performed 2554852 exchanges in 1506276 iterations (69% increments)
 thread 1 performed 2996243 exchanges in 1947667 iterations (53% increments)
 thread 2 performed 2289139 exchanges in 1240563 iterations (84% increments)
 thread 3 performed 2810976 exchanges in 1762400 iterations (59% increments)
 # ASSERTION (S7) (3 lines):
 # TEXT: 1. __rw_atomic_exchange (short, short); 33 == 1 failed
 # LINE: 311
 # ASSERTION (S7) (3 lines):
 # TEXT: 2. __rw_atomic_exchange (short, short); 33 == 1 failed
 # LINE: 315
 thread 0 starting
 thread 3 starting
 thread 1 starting
 thread 2 starting
 thread 0 performed 3487158 exchanges in 2438582 iterations (42% increments)
 thread 1 performed 2938034 exchanges in 1889458 iterations (55% increments)
 thread 2 performed 3610858 exchanges in 2562282 iterations (40% increments)
 thread 3 performed 2949089 exchanges in 1900513 iterations (55% increments)
 thread 0 starting
 thread 3 starting
 thread 2 starting
 thread 1 starting
 thread 0 performed 2453557 exchanges in 1404981 iterations (74% increments)
 thread 1 performed 2343445 exchanges in 1294869 iterations (80% increments)
 thread 2 performed 2304791 exchanges in 1256215 iterations (83% increments)
 thread 3 performed 2342867 exchanges in 1294291 iterations (81% increments)
 thread 0 starting
 thread 2 starting
 thread 1 starting
 thread 3 starting
 thread 0 performed 5889215 exchanges in 4840639 iterations (21% increments)
 thread 1 performed 2959813 exchanges in 1911237 iterations (54% increments)
 thread 2 performed 2786398 exchanges in 1737822 iterations (60% increments)
 thread 3 performed 3926325 exchanges in 2877749 iterations (36% increments)
 thread 0 starting
 thread 1 starting
 thread 2 starting
 thread 3 starting
 thread 0 performed 2257405 exchanges in 1208829 iterations (86% increments)
 thread 1 performed 2468463 exchanges in 1419887

[jira] [Created] (STDCXX-1069) [Sun C++/Linux]

2012-09-23 Thread Liviu Nicoara (JIRA) 
Liviu Nicoara created STDCXX-1069:
-

 Summary: [Sun C++/Linux]
 Key: STDCXX-1069
 URL: https://issues.apache.org/jira/browse/STDCXX-1069
 Project: C++ Standard Library
  Issue Type: Bug
  Components: Build and Installation
Affects Versions: 4.2.x
 Environment: $ uname -a; CC -V
Linux behemoth 2.6.37.6 #3 SMP Sat Apr 9 22:49:32 CDT 2011 x86_64 AMD 
Opteron(tm) Processor 6134 AuthenticAMD GNU/Linux
CC: Sun C++ 5.12 Linux_i386 2011/11/16

Reporter: Liviu Nicoara
Priority: Minor
 Fix For: 4.2.x, 4.3.x, 5.0.0


$ nice make -Clib setlocale.o
make: Entering directory `builddir/12S-sunpro-5.12/lib'
generating dependencies for $(TOPDIR)/src/setlocale.cpp
CC -xM -mt -Ibuilddir/include -Ibuilddir/12S-sunpro-5.12/include  
-library=%none -O  -m64 +w -errtags -erroff=hidef   builddir/src/setlocale.cpp
make: Leaving directory `builddir/12S-sunpro-5.12/lib'
make: Entering directory `builddir/12S-sunpro-5.12/lib'
CC -c -mt -Ibuilddir/include -Ibuilddir/12S-sunpro-5.12/include  
-library=%none -O  -m64 +w -errtags -erroff=hidef
builddir/src/setlocale.cpp
/opt/sunpro/12_3/prod/include/cc/wchar.h, line 92: Error, undefidenterr: 
fgetwc is not defined.
/opt/sunpro/12_3/prod/include/cc/wchar.h, line 93: Error, undefidenterr: 
fgetws is not defined.
/opt/sunpro/12_3/prod/include/cc/wchar.h, line 94: Error, undefidenterr: 
fputwc is not defined.
/opt/sunpro/12_3/prod/include/cc/wchar.h, line 95: Error, undefidenterr: 
fputws is not defined.
/opt/sunpro/12_3/prod/include/cc/wchar.h, line 96: Error, undefidenterr: 
getwc is not defined.
/opt/sunpro/12_3/prod/include/cc/wchar.h, line 97: Error, undefidenterr: 
getwchar is not defined.
/opt/sunpro/12_3/prod/include/cc/wchar.h, line 98: Error, undefidenterr: 
putwc is not defined.
/opt/sunpro/12_3/prod/include/cc/wchar.h, line 99: Error, undefidenterr: 
putwchar is not defined.
/opt/sunpro/12_3/prod/include/cc/wchar.h, line 100: Error, undefidenterr: 
ungetwc is not defined.
/opt/sunpro/12_3/prod/include/cc/wchar.h, line 102: Error, undefidenterr: 
wcsftime is not defined.
/opt/sunpro/12_3/prod/include/cc/wchar.h, line 103: Error, undefidenterr: 
wcstod is not defined.
/opt/sunpro/12_3/prod/include/cc/wchar.h, line 104: Error, undefidenterr: 
wcstol is not defined.
/opt/sunpro/12_3/prod/include/cc/wchar.h, line 105: Error, undefidenterr: 
wcstoul is not defined.
/opt/sunpro/12_3/prod/include/cc/wchar.h, line 106: Error, undefidenterr: 
wcscpy is not defined.
/opt/sunpro/12_3/prod/include/cc/wchar.h, line 107: Error, undefidenterr: 
wcsncpy is not defined.
/opt/sunpro/12_3/prod/include/cc/wchar.h, line 108: Error, undefidenterr: 
wcscat is not defined.
/opt/sunpro/12_3/prod/include/cc/wchar.h, line 109: Error, undefidenterr: 
wcsncat is not defined.
/opt/sunpro/12_3/prod/include/cc/wchar.h, line 110: Error, undefidenterr: 
wcscmp is not defined.
/opt/sunpro/12_3/prod/include/cc/wchar.h, line 111: Error, undefidenterr: 
wcsncmp is not defined.
/opt/sunpro/12_3/prod/include/cc/wchar.h, line 112: Error, undefidenterr: 
wcscoll is not defined.
/opt/sunpro/12_3/prod/include/cc/wchar.h, line 113: Error, undefidenterr: 
wcsxfrm is not defined.
/opt/sunpro/12_3/prod/include/cc/wchar.h, line 114: Error, undefidenterr: 
wcschr is not defined.
/opt/sunpro/12_3/prod/include/cc/wchar.h, line 115: Error, undefidenterr: 
wcscspn is not defined.
/opt/sunpro/12_3/prod/include/cc/wchar.h, line 116: Error, undefidenterr: 
wcslen is not defined.
/opt/sunpro/12_3/prod/include/cc/wchar.h, line 117: Error, undefidenterr: 
wcspbrk is not defined.
Compilation aborted, too many Error messages.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (STDCXX-1069) [Sun C++/Linux]

2012-09-23 Thread Liviu Nicoara (JIRA) 

 [ 
https://issues.apache.org/jira/browse/STDCXX-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Liviu Nicoara updated STDCXX-1069:
--

Attachment: stdcxx-1069.patch

 [Sun C++/Linux]
 ---

 Key: STDCXX-1069
 URL: https://issues.apache.org/jira/browse/STDCXX-1069
 Project: C++ Standard Library
  Issue Type: Bug
  Components: Build and Installation
Affects Versions: 4.2.x
 Environment: $ uname -a; CC -V
 Linux behemoth 2.6.37.6 #3 SMP Sat Apr 9 22:49:32 CDT 2011 x86_64 AMD 
 Opteron(tm) Processor 6134 AuthenticAMD GNU/Linux
 CC: Sun C++ 5.12 Linux_i386 2011/11/16
Reporter: Liviu Nicoara
Priority: Minor
  Labels: AMD64, Linux, Solaris, Studio, Sun, _XOPEN_SOURCE, x86_64
 Fix For: 4.2.x, 4.3.x, 5.0.0

 Attachments: stdcxx-1069.patch

   Original Estimate: 1m
  Remaining Estimate: 1m

 $ nice make -Clib setlocale.o
 make: Entering directory `builddir/12S-sunpro-5.12/lib'
 generating dependencies for $(TOPDIR)/src/setlocale.cpp
 CC -xM -mt -Ibuilddir/include -Ibuilddir/12S-sunpro-5.12/include  
 -library=%none -O  -m64 +w -errtags -erroff=hidef   
 builddir/src/setlocale.cpp
 make: Leaving directory `builddir/12S-sunpro-5.12/lib'
 make: Entering directory `builddir/12S-sunpro-5.12/lib'
 CC -c -mt -Ibuilddir/include -Ibuilddir/12S-sunpro-5.12/include  
 -library=%none -O  -m64 +w -errtags -erroff=hidef
 builddir/src/setlocale.cpp
 /opt/sunpro/12_3/prod/include/cc/wchar.h, line 92: Error, undefidenterr: 
 fgetwc is not defined.
 /opt/sunpro/12_3/prod/include/cc/wchar.h, line 93: Error, undefidenterr: 
 fgetws is not defined.
 /opt/sunpro/12_3/prod/include/cc/wchar.h, line 94: Error, undefidenterr: 
 fputwc is not defined.
 /opt/sunpro/12_3/prod/include/cc/wchar.h, line 95: Error, undefidenterr: 
 fputws is not defined.
 /opt/sunpro/12_3/prod/include/cc/wchar.h, line 96: Error, undefidenterr: 
 getwc is not defined.
 /opt/sunpro/12_3/prod/include/cc/wchar.h, line 97: Error, undefidenterr: 
 getwchar is not defined.
 /opt/sunpro/12_3/prod/include/cc/wchar.h, line 98: Error, undefidenterr: 
 putwc is not defined.
 /opt/sunpro/12_3/prod/include/cc/wchar.h, line 99: Error, undefidenterr: 
 putwchar is not defined.
 /opt/sunpro/12_3/prod/include/cc/wchar.h, line 100: Error, undefidenterr: 
 ungetwc is not defined.
 /opt/sunpro/12_3/prod/include/cc/wchar.h, line 102: Error, undefidenterr: 
 wcsftime is not defined.
 /opt/sunpro/12_3/prod/include/cc/wchar.h, line 103: Error, undefidenterr: 
 wcstod is not defined.
 /opt/sunpro/12_3/prod/include/cc/wchar.h, line 104: Error, undefidenterr: 
 wcstol is not defined.
 /opt/sunpro/12_3/prod/include/cc/wchar.h, line 105: Error, undefidenterr: 
 wcstoul is not defined.
 /opt/sunpro/12_3/prod/include/cc/wchar.h, line 106: Error, undefidenterr: 
 wcscpy is not defined.
 /opt/sunpro/12_3/prod/include/cc/wchar.h, line 107: Error, undefidenterr: 
 wcsncpy is not defined.
 /opt/sunpro/12_3/prod/include/cc/wchar.h, line 108: Error, undefidenterr: 
 wcscat is not defined.
 /opt/sunpro/12_3/prod/include/cc/wchar.h, line 109: Error, undefidenterr: 
 wcsncat is not defined.
 /opt/sunpro/12_3/prod/include/cc/wchar.h, line 110: Error, undefidenterr: 
 wcscmp is not defined.
 /opt/sunpro/12_3/prod/include/cc/wchar.h, line 111: Error, undefidenterr: 
 wcsncmp is not defined.
 /opt/sunpro/12_3/prod/include/cc/wchar.h, line 112: Error, undefidenterr: 
 wcscoll is not defined.
 /opt/sunpro/12_3/prod/include/cc/wchar.h, line 113: Error, undefidenterr: 
 wcsxfrm is not defined.
 /opt/sunpro/12_3/prod/include/cc/wchar.h, line 114: Error, undefidenterr: 
 wcschr is not defined.
 /opt/sunpro/12_3/prod/include/cc/wchar.h, line 115: Error, undefidenterr: 
 wcscspn is not defined.
 /opt/sunpro/12_3/prod/include/cc/wchar.h, line 116: Error, undefidenterr: 
 wcslen is not defined.
 /opt/sunpro/12_3/prod/include/cc/wchar.h, line 117: Error, undefidenterr: 
 wcspbrk is not defined.
 Compilation aborted, too many Error messages.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe

2012-09-23 Thread Liviu Nicoara (JIRA) 

[ 
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461452#comment-13461452
 ] 

Liviu Nicoara commented on STDCXX-1056:
---

This summarizes the findings that occurred during the long (!) discussion on 
the mailing list:

1. Data caching in the facet object, and the access to it, was improperly 
guarded
2. Concurrent modification of the same string member (via same handle) occurs
3. Stefan identified race conditions in the locale/facet code, beyond caching
4. Stefan provided a clean, race-free patch (although its scope is contested)
5. Alternatively, the simple elimination of locale data caching eliminates test 
suite failures

Besides the obvious defect in caching, DCII occurs in the facet initialization 
code which would make it thread unsafe although we don't currently have a 
failing test case.

The patch from Stefan eliminates all race conditions and effectively 
synchronizes all access to facet data. Performance data is not available. It is 
very possible that this strict synchronization matters very little in the 
overall picture of the localization library performance.

Alternatively, the simplest and least invasive solution at the moment is to 
just eliminate the caching code. This keeps the fast, unguarded reads of the 
facet data and relies on the (disputed) thread-safety of the facet 
initialization code. Timings showed better performance on SMP than the cached 
facet, and way worse in ST. It also plays in future development with a 
non-reference counted std::string.

The DCII is a serious matter even though there is no failing test case yet. A 
memory barrier API, recognized by the compiler, would allow us to preserve the 
fast, unguarded reads of facet data (and even caching).

 std::moneypunct and std::numpunct implementations are not thread-safe
 -

 Key: STDCXX-1056
 URL: https://issues.apache.org/jira/browse/STDCXX-1056
 Project: C++ Standard Library
  Issue Type: Bug
  Components: 22. Localization
Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0
 Environment: Solaris 10 and 11, RedHat and OpenSuSE Linux, Sun C++ 
 Compilers 12.1, 12.2, 12.3
 Issue is independent of platform and/or compiler.
Reporter: Stefan Teleman
  Labels: thread-safety
 Fix For: 4.2.x, 4.3.x, 5.0.0

 Attachments: 22.locale.numpunct.mt.out, runtests-linux32-all.out, 
 runtests-linux64-all.out, runtests.out, STDCXX-1056-additional-timings.tgz, 
 stdcxx-1056.patch, stdcxx-1056-timings.tgz, 
 stdcxx-4.2.x-numpunct-perfect-forwarding.patch, 
 stdcxx-4.3.x-numpunct-perfect-forwarding.patch


 several member functions in std::moneypunct and std::numpunct return
 a std::string by value (as required by the Standard). The implication of 
 return-by-value
 being that the caller owns the returned object.
 In the stdcxx implementation, the std::basic_string copy constructor uses a 
 shared
 underlying buffer implementation. This shared buffer creates the first 
 problem for
 these classes: although the std::string object returned by value *appears* to 
 be owned
 by the caller, it is, in fact, not.
 In a mult-threaded environment, this underlying shared buffer can be 
 subsequently modified by a different thread than the one who made the initial 
 call. Furthermore, two or more different threads can access the same shared 
 buffer at the same time, and modify it, resulting in undefined run-time 
 behavior.
 The cure for this defect has two parts:
 1. the member functions in question must truly return a copy by avoiding a 
 call to the copy constructor, and using a constructor which creates a deep 
 copy of the std::string.
 2. access to these member functions must be serialized, in order to guarantee 
 atomicity
 of the creation of the std::string being returned by value.
 Patch for 4.2.1 to follow.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe

2012-09-23 Thread Stefan Teleman (JIRA) 

 [ 
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Teleman updated STDCXX-1056:
---

Attachment: facet.cpp.diff

facet.cpp patch for STDCXX-1056 based on 4.2.1.

 std::moneypunct and std::numpunct implementations are not thread-safe
 -

 Key: STDCXX-1056
 URL: https://issues.apache.org/jira/browse/STDCXX-1056
 Project: C++ Standard Library
  Issue Type: Bug
  Components: 22. Localization
Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0
 Environment: Solaris 10 and 11, RedHat and OpenSuSE Linux, Sun C++ 
 Compilers 12.1, 12.2, 12.3
 Issue is independent of platform and/or compiler.
Reporter: Stefan Teleman
  Labels: thread-safety
 Fix For: 4.2.x, 4.3.x, 5.0.0

 Attachments: 22.locale.numpunct.mt.out, facet.cpp.diff, 
 locale_body.cpp.diff, runtests-linux32-all.out, runtests-linux64-all.out, 
 runtests.out, STDCXX-1056-additional-timings.tgz, stdcxx-1056.patch, 
 stdcxx-1056-timings.tgz, stdcxx-4.2.x-numpunct-perfect-forwarding.patch, 
 stdcxx-4.3.x-numpunct-perfect-forwarding.patch


 several member functions in std::moneypunct and std::numpunct return
 a std::string by value (as required by the Standard). The implication of 
 return-by-value
 being that the caller owns the returned object.
 In the stdcxx implementation, the std::basic_string copy constructor uses a 
 shared
 underlying buffer implementation. This shared buffer creates the first 
 problem for
 these classes: although the std::string object returned by value *appears* to 
 be owned
 by the caller, it is, in fact, not.
 In a mult-threaded environment, this underlying shared buffer can be 
 subsequently modified by a different thread than the one who made the initial 
 call. Furthermore, two or more different threads can access the same shared 
 buffer at the same time, and modify it, resulting in undefined run-time 
 behavior.
 The cure for this defect has two parts:
 1. the member functions in question must truly return a copy by avoiding a 
 call to the copy constructor, and using a constructor which creates a deep 
 copy of the std::string.
 2. access to these member functions must be serialized, in order to guarantee 
 atomicity
 of the creation of the std::string being returned by value.
 Patch for 4.2.1 to follow.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe

2012-09-23 Thread Stefan Teleman (JIRA) 

 [ 
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Teleman updated STDCXX-1056:
---

Attachment: locale_body.cpp.diff

locale_body.cpp  patch for STDCXX-1056 based on stdcxx 4.2.1.

 std::moneypunct and std::numpunct implementations are not thread-safe
 -

 Key: STDCXX-1056
 URL: https://issues.apache.org/jira/browse/STDCXX-1056
 Project: C++ Standard Library
  Issue Type: Bug
  Components: 22. Localization
Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0
 Environment: Solaris 10 and 11, RedHat and OpenSuSE Linux, Sun C++ 
 Compilers 12.1, 12.2, 12.3
 Issue is independent of platform and/or compiler.
Reporter: Stefan Teleman
  Labels: thread-safety
 Fix For: 4.2.x, 4.3.x, 5.0.0

 Attachments: 22.locale.numpunct.mt.out, facet.cpp.diff, 
 locale_body.cpp.diff, runtests-linux32-all.out, runtests-linux64-all.out, 
 runtests.out, STDCXX-1056-additional-timings.tgz, stdcxx-1056.patch, 
 stdcxx-1056-timings.tgz, stdcxx-4.2.x-numpunct-perfect-forwarding.patch, 
 stdcxx-4.3.x-numpunct-perfect-forwarding.patch


 several member functions in std::moneypunct and std::numpunct return
 a std::string by value (as required by the Standard). The implication of 
 return-by-value
 being that the caller owns the returned object.
 In the stdcxx implementation, the std::basic_string copy constructor uses a 
 shared
 underlying buffer implementation. This shared buffer creates the first 
 problem for
 these classes: although the std::string object returned by value *appears* to 
 be owned
 by the caller, it is, in fact, not.
 In a mult-threaded environment, this underlying shared buffer can be 
 subsequently modified by a different thread than the one who made the initial 
 call. Furthermore, two or more different threads can access the same shared 
 buffer at the same time, and modify it, resulting in undefined run-time 
 behavior.
 The cure for this defect has two parts:
 1. the member functions in question must truly return a copy by avoiding a 
 call to the copy constructor, and using a constructor which creates a deep 
 copy of the std::string.
 2. access to these member functions must be serialized, in order to guarantee 
 atomicity
 of the creation of the std::string being returned by value.
 Patch for 4.2.1 to follow.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe

2012-09-23 Thread Stefan Teleman (JIRA) 

 [ 
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Teleman updated STDCXX-1056:
---

Attachment: punct.cpp.diff

punct.cpp patch for STDCXX-1056 based on stdcxx 4.2.1.

 std::moneypunct and std::numpunct implementations are not thread-safe
 -

 Key: STDCXX-1056
 URL: https://issues.apache.org/jira/browse/STDCXX-1056
 Project: C++ Standard Library
  Issue Type: Bug
  Components: 22. Localization
Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0
 Environment: Solaris 10 and 11, RedHat and OpenSuSE Linux, Sun C++ 
 Compilers 12.1, 12.2, 12.3
 Issue is independent of platform and/or compiler.
Reporter: Stefan Teleman
  Labels: thread-safety
 Fix For: 4.2.x, 4.3.x, 5.0.0

 Attachments: 22.locale.numpunct.mt.out, facet.cpp.diff, 
 locale_body.cpp.diff, punct.cpp.diff, runtests-linux32-all.out, 
 runtests-linux64-all.out, runtests.out, STDCXX-1056-additional-timings.tgz, 
 stdcxx-1056.patch, stdcxx-1056-timings.tgz, 
 stdcxx-4.2.x-numpunct-perfect-forwarding.patch, 
 stdcxx-4.3.x-numpunct-perfect-forwarding.patch


 several member functions in std::moneypunct and std::numpunct return
 a std::string by value (as required by the Standard). The implication of 
 return-by-value
 being that the caller owns the returned object.
 In the stdcxx implementation, the std::basic_string copy constructor uses a 
 shared
 underlying buffer implementation. This shared buffer creates the first 
 problem for
 these classes: although the std::string object returned by value *appears* to 
 be owned
 by the caller, it is, in fact, not.
 In a mult-threaded environment, this underlying shared buffer can be 
 subsequently modified by a different thread than the one who made the initial 
 call. Furthermore, two or more different threads can access the same shared 
 buffer at the same time, and modify it, resulting in undefined run-time 
 behavior.
 The cure for this defect has two parts:
 1. the member functions in question must truly return a copy by avoiding a 
 call to the copy constructor, and using a constructor which creates a deep 
 copy of the std::string.
 2. access to these member functions must be serialized, in order to guarantee 
 atomicity
 of the creation of the std::string being returned by value.
 Patch for 4.2.1 to follow.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe

2012-09-23 Thread Stefan Teleman (JIRA) 

[ 
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461490#comment-13461490
 ] 

Stefan Teleman commented on STDCXX-1056:


The thing I *don't* like about my patch set at all is that it doesn't really 
and completely eliminate the cache resize problem, which I strongly suspect is 
the root cause of the race conditions, although I do not have a bull's eye 
proof for it yet. I have plenty of circumstantial evidence. ;-)

Regardless of the initial cache size we start with, it is still possible that 
the cache will have to be resized. Right now, the fix relies on the fact that 
it is *unlikely* that a program will ever need more than 32 locales, and the 
cache never needs to be resized.

The reason the perfect forwarding patch appears to solve the problem is: the 
instantiation of the std::string returned-by-value by the facet member 
functions is now different: the do_*() functions return a (cast-to) _CharT* 
pointer. Because of this, the std::string returned by value is now constructed 
as a deep copy (see the string::string(const _CharT*) 21.3.1/P9 constructor), 
which effectively gives ownership of this string to the caller - this 
constructor calls traits_type::copy (_C_data, __s, __n);.

For one, the timing difference caused by having to copy the bits (in the 
constructor) is enough to alter the run-time behavior. Second, by owning a deep 
copy of the returned string, the caller will still have the bits, although the 
facet object itself may have long disappeared.

Latest files, diffs and test results are available here:

 http://s247136804.onlinehome.us/stdcxx-1056-20120922/

In this latest version I also fixed a bug I had in my original patchset.

The diffs are next-to-impossible to read. It is much easier to just read the 
complete files.

The changes I made are in:

locale_body.cpp:

__rw_locale* __rw_locale::_C_manage ( ... );

facet.cpp:

__rw_facet* __rw_facet::_C_manage ( ... );

punct.cpp:

static const void* __rw_get_numpunct ( ... );
static const void* __rw_get_moneypunct ( ... );

In punct.cpp there are two new static inline functions:

static inline const void* __rw_numpunct_switch ( ... );
static inline const void* __rw_moneypunct_switch ( ... );

These two functions are used in replacing the recursive calls present in the 
original implementation of __rw_get_numpunct() and __rw_get_moneypunct(). Their 
names are horrible. 

Recursion is extremely expensive on SPARC (and I strongly suspect on other RISC 
machines as well).

I will provide performance data next week. To produce relevant performance 
data, I need to do optimized builds. Instrumentation requires non-optimized 
debug builds, and the instrumentation part is what I've been focusing on for 
the past week.








 

 std::moneypunct and std::numpunct implementations are not thread-safe
 -

 Key: STDCXX-1056
 URL: https://issues.apache.org/jira/browse/STDCXX-1056
 Project: C++ Standard Library
  Issue Type: Bug
  Components: 22. Localization
Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0
 Environment: Solaris 10 and 11, RedHat and OpenSuSE Linux, Sun C++ 
 Compilers 12.1, 12.2, 12.3
 Issue is independent of platform and/or compiler.
Reporter: Stefan Teleman
  Labels: thread-safety
 Fix For: 4.2.x, 4.3.x, 5.0.0

 Attachments: 22.locale.numpunct.mt.out, facet.cpp.diff, 
 locale_body.cpp.diff, punct.cpp.diff, runtests-linux32-all.out, 
 runtests-linux64-all.out, runtests.out, STDCXX-1056-additional-timings.tgz, 
 stdcxx-1056.patch, stdcxx-1056-timings.tgz, 
 stdcxx-4.2.x-numpunct-perfect-forwarding.patch, 
 stdcxx-4.3.x-numpunct-perfect-forwarding.patch


 several member functions in std::moneypunct and std::numpunct return
 a std::string by value (as required by the Standard). The implication of 
 return-by-value
 being that the caller owns the returned object.
 In the stdcxx implementation, the std::basic_string copy constructor uses a 
 shared
 underlying buffer implementation. This shared buffer creates the first 
 problem for
 these classes: although the std::string object returned by value *appears* to 
 be owned
 by the caller, it is, in fact, not.
 In a mult-threaded environment, this underlying shared buffer can be 
 subsequently modified by a different thread than the one who made the initial 
 call. Furthermore, two or more different threads can access the same shared 
 buffer at the same time, and modify it, resulting in undefined run-time 
 behavior.
 The cure for this defect has two parts:
 1. the member functions in question must truly return a copy by avoiding a 
 call to the copy constructor, and using a constructor which creates a deep 
 copy of the std::string.
 2. access to these member