stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: string methods thread safety
Date Thu, 06 Jul 2006 02:04:06 GMT
Anton Pevtsov wrote:
> I updated the test to use the test driver
> features and extended it to exercise the append and replace methods in
> the same way.
> The test and required changes are here:

I've run out of time today. Let me look at it tomorrow and get
back to you. At a high level, though, I don't think we should
be using the test driver (i.e., the 21.strings.cpp framework)
in the thread safety tests. Also, keep in mind that the rest
of the driver (e.g., rw_assert()) is not thread-safe either.
I think the thread safety tests should only use the assert

I have a semi-exhaustive thread safety test for sting stashed
away somewhere. Let me dig it up and post it to give you an

> I found the tricky place in the rwthread.cpp, line 397:
> 	void* const next_arg = thr_arg ? thr_arg + i : (void*)(thr_id +
> i);
> I suspect here should be
> 	void* const next_arg = thr_arg ? *(thr_arg + i) : (void*)(thr_id
> + i);
> The fix included.

Let me look into this tomorrow.

> Also I have several questions.
> 1. The test becomes slow due to a huge amount of asserts to be verified.
> I think that we should exercise the multithreading on several test cases
> per eaach method, but shall we use all our char and allocator types for
> this purpose?

Yes, we should exercise only a small number of functions in each
run of the test. The test program itself can be written so as to
exercise a larger number of string functions but which ones are
actually executed should be controlled via a command line option.

> 2. Martin, you have mentioned
> (
> ox/ that
> "We need to write thread safety tests for other member functions as well
> (not necessarily all of them but at least those that we know are used a
> lot. The most important ones are those that call _C_get_ref(), i.e., the
> copy ctor, assignment operator, begin(), append(const string&), and
> replace()."
> But as far as I see the begin method will fail the test if I didn't miss
> something.

You mean because the non-const version triggers COW?

> 3. The test looks useless in the single-threaded environment. May be we
> should provide a stub for this cases and not run the test (or run and do
> nothing) for these cases?

Yes, definitely. The test should be a no-op in a single threaded


View raw message