>-----Original Message-----
>From: Martin Sebor [mailto:[EMAIL PROTECTED]
>Sent: Friday, August 10, 2007 1:42 PM
>To: stdcxx-dev@incubator.apache.org
>Subject: Re: [PATCH] Update test 22.locale.num.put.mt.cpp to
>validate results
>
>Travis Vitek wrote:
>
>>
>>
>> Martin Sebor wrote:
>>
>>>We can't be using rw_assert() in a thread function (the driver
>>>isn't thread safe yet, and if it was it would unnecessarily
>>>synchronize the threads). Use the RW_ASSERT() macro instead.
>>>
>>
>>
>> I think there will be a lot of useful context that is lost if
>> I switch to RW_ASSERT. It would be especially useful to know
>> the active locale, the input value, and the output values in
>> these test cases.
>
>These values are invaluable when the tests fail due to a problem
>other than a thread safety bug in the library but I'm not sure
>they would be of much use in the case of a thread safety bug
>that manifests itself by corrupting data. Do you have specific
>scenario in mind where this information would be useful?
>
>
One example that I ran into in my limited testing was that a locale
was getting created with the correct name, but it was not the correct
locale that was getting used. The data wasn't corrupt, it was just
for the wrong locale.
# INFO (S1) (3 lines):
# TEXT: testing std::time_put<charT> with 4 threads, 100000 iterations
each, in locales { "en_US" "es_MX" }
# CLAUSE: lib.locale.time.put
# WARNING (S5) (3 lines):
# TEXT: locale="en_US" output="jue" expected="Thu"
# CLAUSE: lib.locale.time.put
Sure this is a threading bug, but IMO the generated message is more
useful than the other option
/amd/devco/vitek/stdcxx/trunk/tests/localization/22.locale.time.put.mt.c
pp:177: void* thread_func(void*): Assertion '!rw_strncmp(ncs,
data.ncs_)' failed.
/nfs/devbuild/vitek/stdcxx/trunk/linux.gcc/lib/libstd15d.so[0xea7b16]
/nfs/devbuild/vitek/stdcxx/trunk/linux.gcc/lib/libstd15d.so(_ZN4__rw16__
rw_assert_failEPKcS1_iS1_+0x6e)[0xea7bae]
./22.locale.time.put.mt[0x804c08a]
/lib/tls/libpthread.so.0[0x6c3371]
/lib/tls/libc.so.6(__clone+0x5e)[0x52affe]
Aborted
The other nice thing is that the test will continue, possibly exposing
additional problems.
>>
>> I'm thinking of doing something like this in each of the facet
>> tests.
>>
>> _RW::__rw_synchronized __driver_syncronize;
>
>This would introduce a dependency of the test on the correct
>behavior of component that is being tested. To do something like
>this we'd need to introduce a separate synchronization mechanism
>into the test driver.
Agreed. Ugh.
>But I'm not sure that'll be necessary. I'd
>rather avoid any kind of synchronization in the thread function.
>If you do want to make this information available, I suggest
>returning it from the thread function to the main thread in the
>form of indices into the data array and having the main thread
>display it in a call to rw_fatal().
Yes, that would be another workable solution. Honestly I'm hoping that
once these tests are up and running the bugs will be found and there
won't be any problems to speak of. If that is the case, then all of this
discussion is moot.
Travis
