Re: std::string bad design????
Seungbeom Kim wrote:
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.)
Yes speculate correctly - it removes an element from the container.
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().)
Yes. But the acquiring and releasing is not expensive at all. The
solution, which I want to emphasize for the others reading this post
(not you) should not be tried in plain C++, is to execute an atomic,
inexpensive attempt to grab the lock (atomic-test and set /
atomic-swap, etc.), and if that fails, fail-over to a full blown
kernel-mode mutex, which you would have had to do anyway. This is very
fast.
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!
I see what you mean. This is a function of how the
Your iterator model suffers from exactly the same problem.
No it does not. My containers do not use global variables. I am
guessing that you did not say that either, that you mean, if i have one
of my containers with its internal iterators, and Thread A acquires,
does something, and releases, Thread B acquires, does something, and
releases, the next time Thread A comes back, the iterator inside the
container will not be where Thread A left it. ??
If you are saying this, I guess the only thing I can say is that this
never happens in practice.
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.
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.
Again I see what you mean.
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.
This is the correct approach IMO. I remember long ago in the early
days of C thinking this would be a problem in multi-threaded
applications. I do not think the library designers should have done
this. I call this the Walk-The-Line principle, which I learned from a
Belgian who was a guest visiting me in the United States. She kept
herself so neat, her entire set of belongings, toothbrush, toothpaste,
books, purse, luggage, shopping items, everything, never deviated from
a space more than 1 meter X 1 meter. It all sat in a neat square, in
that part of my home where I would not have walked anyway. She gave new
meaning to the concept of minimal intrusion. I think the same could be
done with functions like localtime and strtok. The design that has
least ramifications might have been to keep everything as stateless as
possible. Fortunately, C++ makes this concept very easy to realize in
practice.
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.
I thought I had mentioned this, but whenever I write .LHE() or .RHE()
on one of my containers, I get by reference the stored element. That
means I can also get the address of the element as it sits in the
container, and once I have the address, I effectively have an iterator.
Not that I would follow this model (I would rather supply as many
useful member functions as possible), but if I did, I would do
essentially the same thing above, keeping the address of the outerloop
element steady, while advancing forward in the inner-loop. The only
difference I can see is that, to keep from doing unnecessary work, I
would go forward and backward in the inner-loop.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]