Re: std::string bad design????
Le Chaud Lapin wrote:
Seungbeom Kim wrote:
Hi Seungbeom,
Now, imagine several threads calling locate() and RHE() on the same
phonebook to retrieve phone numbers of several people, without any
modification at all. You have to make sure that no other threads
intervene between the two calls in a thread, or the output will be
meaningless.
You mean like this?:
multicache.acquire();
if
(multicache.targets_of_termination.locate(targets_of_termination.LHE())
&&
multicache.targets_of_termination.RHE().locate(targets_of_termination.RHE())
)
{
multicache.targets_of_termination.RHE().remove();
if (multicache.targets_of_termination.RHE().is_empty())
multicache.targets_of_termination.remove();
}
multicache.release();
More or less; acquiring and releasing a lock prevents other threads from
intervening. On the other hand, I didn't say anything about modification
such as remove(). (I might be wrong about guessing what the remove()
above does.)
This is real code for a real system has at the very minimum 11 threads,
and could scale up to 80 threads. I make two claims:
1. This code will never have any threading issues.
You're right, but you pay the expensive cost of acquiring and releasing
a lock every time you access the object, even if no modification is
involved. (Essentially because your model actually implies modification
through locate().)
2. Not once, in my dull life, did I ever expect two threads to be able
to operate on (what is effectively) a single global variable, and not
have to worry about contention. I am utterly perplexed that other
people seem to expect otherwise.
It doesn't have to be a global variable; even a local variable of a
function will suffer from the same problem if the function is executed
by multiple threads.
On the other hand, if you finish all modification before spawning
multiple threads, then (typically) it's perfectly fine for multiple
threads to access the same global object without locks.
Recall that there are even cases where many standard functions that had
internal states such as strtok() and the localtime() family are being
replaced by the thread-safe versions that take external states, and what
you advocate is exactly the opposite.
First, local time cannot get the time entirely from internal state
(obviously).
You're missing the point: the point is that localtime() returns a
pointer to static data.
Thread A Thread B
struct tm* t = localtime(&a);
// (overwrites *t)
struct tm* t = localtime(&b);
// (overwrites *t)
// use *t, but oops:
// t points to the data
// corresponding to b, not a!
Your iterator model suffers from exactly the same problem.
Second, I have never used strtok, but I would guess that
it has something to do with taking tokens from a string. [...] If
the designer of strtok decided to using external state with
spin-locking and/or mutual-exclusion, more power to him. The only
reason I can think for doing this is to keep track of next place to
start looking, and perhaps a few other things.
I think you're right here.
But if that is the
case, the the fact that the operation itself _requires_ state is
staring him right in the face, which means, a object-based approach
might be more appropriate. If one argues "but it has to be compatible
with C", I would say, "Do not delude yourself. You either have state,
or you do not. If you do, then either have the caller supply the state
on every invocation, or use global variables and accept the
consequences."
I don't get it. The problem with strtok() is the state (for keeping
track of the next place to start looking, plus whatever else) is
maintained in a static variable inside strtok(), so you cannot use it in
multiple threads concurrently.
You may say you can acquire and release a lock, but the tokenization can
happen as a part of a very long task, in which locking just for the sake
of strtok() may seriously affect the performance. This problem won't
happen with strtok_r() from POSIX, which takes an external buffer.
And you cannot have more than one iterator per container. You say it's
extremely rare, but I would say not. Consider a simple task of finding a
duplicate phone number in O(n?) comparisons, for example. It's almost
impossible (or very difficult) with your design.
That is a function of the data structure and has nothing to do with my
iterator model. How fast does map find duplicate values?
map<int, double> foo; // How fast does map<> find duplicate doubles?
typedef map<int, double> M;
for (M::const_iterator i = foo.begin(); i != foo.end(); ++i) {
for (M::const_iterator j = boost::next(i); j != foo.end(); ++j) {
if (i->second == j->second) {
std::cout << i->first << " and " << j->first;
std::cout << " both have the value " << i->second << '\n';
}
}
}
It does have to do with the iterator model, and not with the data
structure; the same argument holds with vector instead of map, for example.
And you have to give up using constness in such a container, because
just retrieving data results in an observable change in the state of the
container.
That is part of my interface definition. I can have a const container
and a non-const container. The const container provides a contract
that states that no elements can be added, removed, or modified. The
non-const container provides a contract that says all operations are
permitted. In the non-const container, the iterator can still move
around inside because it has been declared mutable.
Anyone who uses my container is fully aware of this contract. What is
more important is that, after using it, they have all agreed that they
willfully accept that the iterator can move in a const container,
meaning, they like the "feel" that the container yields. If anyone had
come to be and said, "You know, I like your containers, but that
iterator being allowed to move around in a const container really
irritates me", I would have taken it out or done something else. What
100% of the programmers who have use these containers have all said is
that it pleasurable to have the iterator on the inside.
So you mean all of them are happy with this:
typedef Associative_Set::<String__, Phone_Number> M;
void foo(const M&);
M phonebook;
phonebook.locate(...);
std::cout << phonebook.RHE() << '\n'; // outputs "08 70 35 19 38"
foo(phonebook);
std::cout << phonebook.RHE() << '\n'; // outputs "08 46 28 24 37"
foo(phonebook);
std::cout << phonebook.RHE() << '\n'; // outputs "08 25 73 52 95"
I don't think I could ever be one of them.
--
Seungbeom Kim
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]