On Mon, Sep 24, 2012 at 8:21 AM, Liviu Nicoara nikko...@hates.ms wrote:
In the light of your inability to answer the simplest questions about the
correctness and usefulness of this patch, I propose we strike the patch in
its entirety.
Let me make something very clear to you: what I am doing
Comments below...
-Original Message-
From: Stefan Teleman
Sent: Monday, September 24, 2012 5:46 AM
Subject: Re: STDCXX-1066 [was: Re: STDCXX forks]
On Mon, Sep 24, 2012 at 8:21 AM, Liviu Nicoara nikko...@hates.ms
wrote:
In the light of your inability to answer the simplest
On 09/16/12 12:03, Stefan Teleman wrote:
On Sat, Sep 15, 2012 at 5:47 PM, Liviu Nicoara nikko...@hates.ms wrote:
I merely wanted to point out that restoring the default packing is not the
same as restoring the packing to the previous value in effect.
Given this, I thought about an alternative
On Sun, Sep 23, 2012 at 3:26 PM, Liviu Nicoara nikko...@hates.ms wrote:
To be honest it's quite bizarre that you cannot share that with us. Is it
really a trade secret? How can that be the case if Oracle customers are also
required to perform the same alignment, perhaps using the same
On 9/23/12 3:48 PM, Stefan Teleman wrote:
On Sun, Sep 23, 2012 at 3:26 PM, Liviu Nicoara nikko...@hates.ms wrote:
To be honest it's quite bizarre that you cannot share that with us. Is it
really a trade secret? How can that be the case if Oracle customers are also
required to perform the same
On Sun, Sep 23, 2012 at 5:23 PM, Stefan Teleman
stefan.tele...@gmail.com wrote:
The second URL says this:
QUOTE
Due to a change in the implementation of the userland mutexes
introduced by CR 6296770 in KU 137111-01, objects of type mutex_t and
pthread_mutex_t must start at 8-byte aligned
On 9/23/12 5:50 PM, Stefan Teleman wrote:
On Sun, Sep 23, 2012 at 5:23 PM, Stefan Teleman
stefan.tele...@gmail.com wrote:
The second URL says this:
QUOTE
Due to a change in the implementation of the userland mutexes
introduced by CR 6296770 in KU 137111-01, objects of type mutex_t and
On Sun, Sep 23, 2012 at 7:25 PM, Liviu Nicoara nikko...@hates.ms wrote:
I am not asking for any other implementation and I am not looking to change
anything. I wish you could explain it to us, but in the absence of trade
secret details I will take an explanation for the questions above.
On 9/17/12 5:42 PM, Liviu Nicoara wrote:
[...]
However, after more careful thought, I think there is a problem there even
though we don't have an objective proof for it, yet.
The writes are not atomic and they function just like DCII, being subject to
both compiler reordering and out of order
On Mon, Sep 17, 2012 at 11:17 AM, Liviu Nicoara nikko...@hates.ms wrote:
I hope you agree that this synchronization is sufficient for the facet
initialization and reading of facet data.
I have reduced the number of reported race conditions in
22.locale.numpunct.mt from 12440:
On 09/18/12 08:55, Stefan Teleman wrote:
On Mon, Sep 17, 2012 at 11:17 AM, Liviu Nicoara nikko...@hates.ms wrote:
I hope you agree that this synchronization is sufficient for the facet
initialization and reading of facet data.
I have reduced the number of reported race conditions in
On Tue, Sep 18, 2012 at 12:43 PM, Liviu Nicoara nikko...@hates.ms wrote:
I am attaching a test program which, while 100% MT-safe, is flagged by
the Solaris thread analyzer.
The program as written is not thread safe. It is reading the value of
the counter variable and performing a zero
On 09/18/12 13:21, Stefan Teleman wrote:
On Tue, Sep 18, 2012 at 12:43 PM, Liviu Nicoara nikko...@hates.ms wrote:
I am attaching a test program which, while 100% MT-safe, is flagged by
the Solaris thread analyzer.
The program as written is not thread safe. It is reading the value of
the
On Tue, Sep 18, 2012 at 4:35 PM, Liviu Nicoara nikko...@hates.ms wrote:
I will concede that I might be wrong and I am open to arguments. I would
accept as a counter-argument this program if you can show a runtime failure.
The the first read of the counter variable is outside a mutex lock
On 09/18/12 18:24, Stefan Teleman wrote:
On Tue, Sep 18, 2012 at 4:35 PM, Liviu Nicoara nikko...@hates.ms wrote:
I will concede that I might be wrong and I am open to arguments. I would
accept as a counter-argument this program if you can show a runtime failure.
The the first read of the
On 9/18/12 7:04 PM, Stefan Teleman wrote:
On Tue, Sep 18, 2012 at 6:42 PM, Liviu Nicoara nikko...@hates.ms wrote:
The first check is indeed an optimization. It is the point of this exercise
to show that the unguarded reads in the localization library are not defects
and the code, simplified in
On Tue, Sep 18, 2012 at 7:38 PM, Liviu Nicoara nikko...@hates.ms wrote:
1. The facet data caching is not MT-safe
2. The facet data initialization (STDCXX or system locales) is safe (*)
3. There is no unit test currently showing a failure in (2)
4. Timing results show that caching may be
On Mon, Sep 17, 2012 at 8:46 AM, Liviu Nicoara nikko...@hates.ms wrote:
In the meantime I would like to stress again that __rw_get_numpunct is
perfectly thread-safe and does not need extra locking for perfect
forwarding.
So, by removing the test for
if (!(_C_flags _RW::__rw_gr))
On 09/17/12 09:51, Stefan Teleman wrote:
On Mon, Sep 17, 2012 at 8:46 AM, Liviu Nicoara nikko...@hates.ms wrote:
In the meantime I would like to stress again that __rw_get_numpunct is
perfectly thread-safe and does not need extra locking for perfect
forwarding.
So, by removing the test for
On Mon, Sep 17, 2012 at 11:17 AM, Liviu Nicoara nikko...@hates.ms wrote:
I hope you agree that this synchronization is sufficient for the facet
initialization and reading of facet data.
Sorry, I do not agree. Two different thread analyzers from two
different compilers written by two different
On 09/17/12 11:21, Stefan Teleman wrote:
On Mon, Sep 17, 2012 at 11:17 AM, Liviu Nicoara nikko...@hates.ms wrote:
I hope you agree that this synchronization is sufficient for the facet
initialization and reading of facet data.
Sorry, I do not agree. Two different thread analyzers from two
Liviu Nicoara nikko...@hates.ms writes:
On 09/17/12 11:21, Stefan Teleman wrote:
On Mon, Sep 17, 2012 at 11:17 AM, Liviu Nicoara nikko...@hates.ms wrote:
I hope you agree that this synchronization is sufficient for the facet
initialization and reading of facet data.
Sorry, I do not agree.
On Mon, Sep 17, 2012 at 11:38 AM, Wojciech Meyer wojciech.me...@arm.com wrote:
so which compilers do fail? You know, some of them might use the same
component.
Intel Compiler/Thread Analyzer on Linux, SunPro Compiler/Thread
Analyzer on Linux and Solaris (Intel and SPARC). All three of them
On Sat, Sep 15, 2012 at 4:53 PM, Liviu Nicoara nikko...@hates.ms wrote:
Now, to clear the confusion I created: the timing numbers I posted in the
attachment stdcxx-1056-timings.tgz to STDCXX-1066 (09/11/2012) showed that a
perfectly forwarding, no caching public interface (exemplified by a
On 9/16/12 3:20 AM, Stefan Teleman wrote:
On Sat, Sep 15, 2012 at 4:53 PM, Liviu Nicoara nikko...@hates.ms wrote:
Now, to clear the confusion I created: the timing numbers I posted in the
attachment stdcxx-1056-timings.tgz to STDCXX-1066 (09/11/2012) showed that a
perfectly forwarding, no
On 9/16/12 11:21 AM, Liviu Nicoara wrote:
On 9/16/12 3:20 AM, Stefan Teleman wrote:
On Sat, Sep 15, 2012 at 4:53 PM, Liviu Nicoara nikko...@hates.ms wrote:
Now, to clear the confusion I created: the timing numbers I posted in the
attachment stdcxx-1056-timings.tgz to STDCXX-1066 (09/11/2012)
On 9/1/12 1:52 PM, Stefan Teleman wrote: On Sat, Sep 1, 2012 at 12:15 PM,
I opened yesterday STDCXX-1066:
https://issues.apache.org/jira/browse/STDCXX-1056
about the pthread_mutex_t/pthread_cond_t alignment on SPARCV8. I'll
have patches done this weekend. Achtung: the patchset is very
On Sat, Sep 15, 2012 at 9:01 AM, Liviu Nicoara nikko...@hates.ms wrote:
That is funny. What compiler are you using? What does the following test
case return for you?
It's the Intel compiler with the patched stdcxx for the wrong case
and GCC 4.7.1 + GNU libstdc++ for the correct case.
GCC +
On 9/15/12 1:51 PM, Stefan Teleman wrote:
On Sat, Sep 15, 2012 at 9:01 AM, Liviu Nicoara nikko...@hates.ms wrote:
That is funny. What compiler are you using? What does the following test
case return for you?
It's the Intel compiler with the patched stdcxx for the wrong case
and GCC 4.7.1 +
On 9/15/12 2:57 PM, Stefan Teleman wrote:
On Sat, Sep 15, 2012 at 1:02 PM, Liviu Nicoara nikko...@hates.ms wrote:
I have read through the patches attached to the incident, then I briefly
read about the SunPro pragma align and pack. Two questions:
1. AFAICT, the use of the packing pragma may
On 9/15/12 5:19 PM, Stefan Teleman wrote:
On Sat, Sep 15, 2012 at 4:57 PM, Liviu Nicoara nikko...@hates.ms wrote:
Yes, but it restores the default packing, not an arbitrary one, potentially
set by the user prior to including our headers. Say, the user sets 2, the
default is 4 and we set 8.
On 09/12/12 00:21, Stefan Teleman wrote:
On Tue, Sep 11, 2012 at 10:18 PM, Liviu Nicoara nikko...@hates.ms wrote:
AFAICT, there are two cases to consider:
1. Using STDCXX locale database initializes the __rw_punct_t data in the
first, properly synchronized pass through __rw_get_numpunct. All
On 9/11/12 9:40 PM, Martin Sebor wrote:
On 09/11/2012 04:15 PM, Stefan Teleman wrote:
On Mon, Sep 10, 2012 at 4:24 PM, Stefan Teleman
I think I have something which doesn't break BC - stay tuned because
I'm testing it now.
OK.
So, here's a possible implementation of __rw_get_numpunct() with
On Tue, Sep 11, 2012 at 10:18 PM, Liviu Nicoara nikko...@hates.ms wrote:
AFAICT, there are two cases to consider:
1. Using STDCXX locale database initializes the __rw_punct_t data in the
first, properly synchronized pass through __rw_get_numpunct. All subsequent
calls use the __rw_punct_t
On Thu, Sep 6, 2012 at 6:43 PM, Stefan Teleman stefan.tele...@gmail.com wrote:
On Thu, Sep 6, 2012 at 4:02 PM, Martin Sebor mse...@gmail.com wrote:
Here's a thought: it's not pretty but how about having
the function initialize the facet? It already has a pointer
to the base class, so it could
On 09/10/2012 10:56 AM, Stefan Teleman wrote:
On Thu, Sep 6, 2012 at 6:43 PM, Stefan Telemanstefan.tele...@gmail.com wrote:
On Thu, Sep 6, 2012 at 4:02 PM, Martin Sebormse...@gmail.com wrote:
Here's a thought: it's not pretty but how about having
the function initialize the facet? It
On Mon, Sep 10, 2012 at 2:21 PM, Liviu Nicoara nikko...@hates.ms wrote:
4. Without caching of grouping values, grouping() delegates always to
do_grouping():
real0m5.668s
user1m11.389s
sys 0m3.952s
FWIW, 22.2.3.1.1 explicitly states that all of the decimal_point(),
grouping(),
On 09/10/12 15:01, Stefan Teleman wrote:
On Mon, Sep 10, 2012 at 2:21 PM, Liviu Nicoara nikko...@hates.ms wrote:
4. Without caching of grouping values, grouping() delegates always to
do_grouping():
real0m5.668s
user1m11.389s
sys 0m3.952s
FWIW, 22.2.3.1.1 explicitly states that
On Mon, Sep 10, 2012 at 1:32 PM, Martin Sebor mse...@gmail.com wrote:
That said, I'd certainly prefer to avoid hacks as much as
possible. This problem could perhaps more cleanly be solved
by having the facet pass a reference to the string (or to
all of its internal data) to modify to the
On 09/06/12 19:54, Martin Sebor wrote:
I'm not sure how easily we can do that. Almost all of locale
is initialized lazily. Some of the layers might depend on the
facets being initialized lazily as well. This was a deliberate
design choice. One of the constraints was to avoid dynamic
On 09/06/12 22:58, Stefan Teleman wrote:
On Thu, Sep 6, 2012 at 7:31 PM, Liviu Nicoara nikko...@hates.ms wrote:
There would be a performance degradation. IMHO, it would be minor and would
simplify the code considerably.
After finally being able to reproduce the defect with SunPro 12.3 on
On 09/07/12 11:58, Stefan Teleman wrote:
On Fri, Sep 7, 2012 at 8:52 AM, Liviu Nicoara nikko...@hates.ms wrote:
On 09/06/12 19:54, Martin Sebor wrote:
Also, does the 27.objects test pass with this patch?
No, it does not. It hangs at the first insertion, line 227. Unfortunately, I
cannot
On Fri, Sep 7, 2012 at 12:23 PM, Liviu Nicoara nikko...@hates.ms wrote:
I get this when launching the debugger:
$ dbx -xexec32 t
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.9' in your
.dbxrc
Reading t
Reading
On 09/05/12 23:51, Martin Sebor wrote:
On 09/05/2012 09:03 PM, Stefan Teleman wrote:
[...]
Agreed.
But: if the choice is between an implementation which [1] breaks ABI
and [2] performs 20% worse -- even in contrived test cases -- than
another implementation [2] which doesn't break ABI, and
On Thu, Sep 6, 2012 at 9:16 AM, Liviu Nicoara nikko...@hates.ms wrote:
I think Stefan is referring to adding a mutex member variable to the facet
in question and breaking binary compatibility. If that is the case I have
confused things when I suggested exactly that, earlier. A cursory read
On 09/06/2012 09:58 AM, Stefan Teleman wrote:
On Thu, Sep 6, 2012 at 9:16 AM, Liviu Nicoaranikko...@hates.ms wrote:
I think Stefan is referring to adding a mutex member variable to the facet
in question and breaking binary compatibility. If that is the case I have
confused things when I
On Thu, Sep 6, 2012 at 2:46 PM, Stefan Teleman stefan.tele...@gmail.com wrote:
[steleman@darthvader][/src/steleman/programming/stdcxx-ss122/stdcxx-4.2.1/build/tests][09/06/2012
14:40:11][1084] ./22.locale.numpunct.mt --nthreads=2 --nloops=100
# INFO (S1) (10 lines):
# TEXT:
# COMPILER:
On Sep 5, 2012, at 4:03 PM, Martin Sebor wrote:
On 09/05/2012 01:33 PM, Liviu Nicoara wrote:
On 09/05/12 15:17, Martin Sebor wrote:
On 09/05/2012 12:40 PM, Liviu Nicoara wrote:
On 09/05/12 14:09, Stefan Teleman wrote:
On Wed, Sep 5, 2012 at 10:52 AM, Martin Sebor mse...@gmail.com wrote:
I'm not sure how easily we can do that. Almost all of locale
is initialized lazily. Some of the layers might depend on the
facets being initialized lazily as well. This was a deliberate
design choice. One of the constraints was to avoid dynamic
initialization or allocation at startup. [...]
On Thu, Sep 6, 2012 at 7:31 PM, Liviu Nicoara nikko...@hates.ms wrote:
There would be a performance degradation. IMHO, it would be minor and would
simplify the code considerably.
After finally being able to reproduce the defect with SunPro 12.3 on x86_64 I
tried to remove the lazy
On 09/05/12 00:51, Stefan Teleman wrote:
On Tue, Sep 4, 2012 at 10:49 PM, Martin Sebor mse...@gmail.com wrote:
template class _CharT
inline string numpunct_CharT::grouping () const
{
if (!(_C_flags _RW::__rw_gr)) {
numpunct* const __self = _RWSTD_CONST_CAST
That's what I wanted to do originally - use a per-object mutext.
Unfortunately the _C_mutex member in rw::__rw_synchronized is static:
That's the wrong __rw_synchronized -- this one is for non-MT builds.
The one we get in MT builds in on line 370.
struct __rw_synchronized
{
// static so
On Wed, Sep 5, 2012 at 10:52 AM, Martin Sebor mse...@gmail.com wrote:
You're right that there is a race here. But the race is benign
because the T2 will assign the same value to the string as T1
did (because the grouping must be the same in the same locale).
This doesn't reallocate the string
On 09/05/12 14:09, Stefan Teleman wrote:
On Wed, Sep 5, 2012 at 10:52 AM, Martin Sebor mse...@gmail.com wrote:
[...]
OK so I did a little bit of testing, after looking at the *right*
__rw_guard class. :-)
I changed the std::numpunct class thusly:
[...]
And then:
template class _CharT
inline
On 09/05/2012 12:40 PM, Liviu Nicoara wrote:
On 09/05/12 14:09, Stefan Teleman wrote:
On Wed, Sep 5, 2012 at 10:52 AM, Martin Sebor mse...@gmail.com wrote:
[...]
OK so I did a little bit of testing, after looking at the *right*
__rw_guard class. :-)
I changed the std::numpunct class thusly:
On 09/05/2012 01:33 PM, Liviu Nicoara wrote:
On 09/05/12 15:17, Martin Sebor wrote:
On 09/05/2012 12:40 PM, Liviu Nicoara wrote:
On 09/05/12 14:09, Stefan Teleman wrote:
On Wed, Sep 5, 2012 at 10:52 AM, Martin Sebor mse...@gmail.com wrote:
[...]
OK so I did a little bit of testing, after
2012/9/5 Stefan Teleman stefan.tele...@gmail.com:
On Tue, Sep 4, 2012 at 9:15 PM, Liviu Nicoara nikko...@hates.ms wrote:
That is good, right?
Yes, it is good. :-)
Could not get an Intel build off the ground on the account of the LIMITS.cpp
test not running to completion because of a
On Wed, Sep 5, 2012 at 4:20 PM, Stefan Teleman stefan.tele...@gmail.com wrote:
But then there's another aspect -- which I probably failed to
highlight in my previous email: the per-object mutex implementation is
20% *slower* than the class-static mutex implementation.
class-static
On Wed, Sep 5, 2012 at 10:55 PM, Martin Sebor mse...@gmail.com wrote:
I suspect the difference is due to the overhead of the repeated
initialization and destruction of the per-object mutex in the
test. The test repeatedly creates (and discards) named locale
objects.
The per-class mutex is
On 09/05/2012 09:03 PM, Stefan Teleman wrote:
On Wed, Sep 5, 2012 at 10:55 PM, Martin Sebor mse...@gmail.com wrote:
I suspect the difference is due to the overhead of the repeated
initialization and destruction of the per-object mutex in the
test. The test repeatedly creates (and discards)
Incidentally, a benchmark that I would expect to be more
representative of real programs than the test we've been
using is one that creates a small number of named locales
up front and then uses each in a loop in each thread (as
opposed to creating and destroying it in each iteration
and thread).
On Sep 4, 2012, at 10:34 AM, Stefan Teleman wrote:
On Tue, Sep 4, 2012 at 7:35 AM, Liviu Nicoara nikko...@hates.ms wrote:
By no means I am dismissing it. It is at the very least an issue of
efficiency. I will try an Intel C++ build on x86_64 at some point today.
What build type was that? I
I recall discussing this when you opened the defect but I'm not
sure what the outcome of the discussion was.
I looked at the code some more just now and I agree with you that
(at least the numpunct) facet isn't thread safe. The premise was
that we didn't need any locking because the facet never
On Tue, Sep 4, 2012 at 10:49 PM, Martin Sebor mse...@gmail.com wrote:
template class _CharT
inline string numpunct_CharT::grouping () const
{
if (!(_C_flags _RW::__rw_gr)) {
numpunct* const __self = _RWSTD_CONST_CAST (numpunct*, this);
_RWSTD_MT_GUARD
On Mon, Sep 3, 2012 at 11:57 PM, Stefan Teleman
stefan.tele...@gmail.com wrote:
On Mon, Sep 3, 2012 at 3:19 PM, Liviu Nicoara nikko...@hates.ms wrote:
I tried, unsuccessfully, to reproduce the failure observed by Martin in
22.locale.moneypunct.mt, in both debug and optimized, wide and narrow
On 08/31/12 12:20, Stefan Teleman wrote:
On Fri, Aug 31, 2012 at 8:40 AM, Liviu Nicoara nikko...@hates.ms wrote:
Stefan's seem like a complete git-ification of the whole Apache repository
but with no changes I could detect.
Not quite. :-)
[...]
The official Oracle port for Solaris 10 and 11,
On 08/31/12 08:58, C. Bergström wrote:
On 08/31/12 07:40 PM, Liviu Nicoara wrote:
Please correct me if I am wrong.
I have seen two forks on github, one belonging to C. Bergstrom/Pathscale and
the other to Stefan Teleman.
The first one contains a number of genuine code changes outside the
On Sat, Sep 1, 2012 at 12:15 PM, Liviu Nicoara nikko...@hates.ms wrote:
Hi Stefan, I have went through the patches. Specifically, I have spent more
time looking in the mutex alignment changes and the C++ C library headers
patches, and I only read the others. In order:
The test extensions
On Sep 1, 2012, at 1:52 PM, Stefan Teleman wrote:
On Sat, Sep 1, 2012 at 12:15 PM, Liviu Nicoara nikko...@hates.ms wrote:
[...]
This pretty much sums up my first impression.
[...]
To begin with: the compiler flags/GNUmakefile changes are very
specific to the SunPro compilers and to our
On 08/31/12 07:40 PM, Liviu Nicoara wrote:
Please correct me if I am wrong.
I have seen two forks on github, one belonging to C.
Bergstrom/Pathscale and the other to Stefan Teleman.
The first one contains a number of genuine code changes outside the
Apache repository, but without canonical
On 08/31/12 08:58, C. Bergström wrote:
On 08/31/12 07:40 PM, Liviu Nicoara wrote:
Please correct me if I am wrong.
I have seen two forks on github, one belonging to C. Bergstrom/Pathscale and
the other to Stefan Teleman.
The first one contains a number of genuine code changes outside the
On 08/31/12 08:10 PM, Liviu Nicoara wrote:
NetBSD also has a fork I believe, but not sure if it's public/status
Do you know where that is?
He just posted his bulk patch
http://www.netbsd.org/~joerg/stdcxx.diff
There's a small amount of CVS noise and we already have one part on our
On Fri, Aug 31, 2012 at 8:40 AM, Liviu Nicoara nikko...@hates.ms wrote:
Stefan's seem like a complete git-ification of the whole Apache repository
but with no changes I could detect.
Not quite. :-)
You are - most likely referring to the svn repo at CVSDude here:
On Aug 31, 2012, at 8:40 AM, Liviu Nicoara nikko...@hates.ms wrote:
Stefan's seem like a complete git-ification of the whole Apache repository
but with no changes I could detect.
FWIW, The ASF supports git so if people think it would help,
all we'd need to do is ask #infra to move stdcxx
On Fri, Aug 31, 2012 at 8:58 AM, C. Bergström
cbergst...@pathscale.com wrote:
He has quite a number of patches and forget where those are kept. I'm
guessing a lot of his fixes target KDE/Qt apps and the Perennial C++VS
testsuite.
http://www.peren.com/pages/cppvs_set.htm
Correction: my
75 matches
Mail list logo
