 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Michiel.Salters@tomtom.co
Guest
|
 Posted: Mon Jan 23, 2006 11:45 pm Post subject: Re: Standard implementation of basic_string |
 |
|
Jens Theisen wrote:
| Quote: | Alberto wrote:
However, the problem arises in a multi-threading environment, if another
thread holds a reference to s and that thread happens to perform a lazy
copy of s between the first call to s.begin() and the call to s.end().
(Notice that the "other" thread did not try to modify s!) Now s.end()
must again unshare the string, but it must do so without invalidating
the iterator already returned by s.begin()!
But presumably you have user-side locked s, so no other thread can access
s anyway. This kind of locking is necessary for any STL container, so it's
not really about the weird iterator invalidation semantics: Even if you're
having a string implementation without COW, it's not likely to be thread
safe without user-side locks.
|
The problem is not locking s. The problem is locking s and any other
string
object which happens to share its representation. Just replace "a lazy
copy
of s" with "a lazy copy of a copy of s" in Alberto's example. Clearly
you
wouldn't lock s just because you're copying old_s?
HTH,
Michiel Salters
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
 |
Jens Theisen
Guest
|
| Posted: Wed Jan 25, 2006 4:42 am Post subject: Re: Standard implementation of basic_string |
|
|
Michiel.Salters wrote:
| Quote: | The problem is not locking s. The problem is locking s and any other
string
object which happens to share its representation. Just replace "a lazy
copy
of s" with "a lazy copy of a copy of s" in Alberto's example. Clearly
you
wouldn't lock s just because you're copying old_s?
|
That's a different problem, yes. There was already a discussion about it
in a different branch of this thread. It's documented in Sutter's More
Exceptional C++.
But as I already said, I have a problem with Sutter's argument.
Presuming the use count's increment is atomical, how should there be a
concurrent write access to a read access (or even another write access)?
On a use count of greater than 1, a write operation will create a new
copy, and that's locked on user side. On a use count of 1, user side
locking is sufficient.
Can you say something to this?
Jens
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
