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 Fri, 21 Jul 2006 00:59:36 GMT
(I lost your post so I'm recreating it from the archive -- it may not
thread properly.)

 >  > -----Original Message-----
 >  > From: Martin Sebor []
 >  > Sent: Friday, July 07, 2006 3:46 AM
 >  > To:
 >  > Subject: Re: string methods thread safety
 >  >
 > [...]
 >  > The thread safety tests I envision for our test suite would
 >  > exercise a subset (as small as a pair) of functions per each
 >  > run. The one constant (as in the same across all test runs)
 >  > function would be the copy ctor (or its equivalent such as
 >  > the assignment operator) and the other a modifying string
 >  > function. The copy ctor would be used to create a copy of a
 >  > shared string object for each thread and the modifying
 >  > function would then operate on the copy.
 >    Martin, I implemented the first draft of the test.
 >    The append method overloads are tested only. Other methods I
 > will append to the test tomorrow.

Could you please post your proposed ChangeLog entry for all nontrivial
changes? It will make it easier for me to understand what's going on.
Thanks! :)

I just looked at this briefly but it looks like the right approach
(or at least like the one I had in mind ;-)

The only thing I'm not quite happy with so far is making _rw_setvars
extern. According to the (still unwritten, my bad) naming convention,
names that start with _rw_ have internal linkage, and shouldn't be
exposed to the world (i.e., to the tests or other objects). If it
turns out that the function is helpful elsewhere besides the TU where
it's declared static we should rename it (and drop the leading
underscore). The burden that should come with doing it is writing
a test for the function. I realize that's a lot of overhead, but
that's intentional. I'm trying to minimize the test driver interface
to make it easier to use. Minimizing it will lead to making it as
generic as possible, which I think is a good thing (i.e., it would
be very nice to be able to use the same part of the driver for both
the string and the container tests.

But I'm afraid I'm running out of time today. Let me get back to
it tomorrow. I'll also try to fix the rw_thread_create() issue
with the argument.


View raw message