Re: thread safety of C++ standard library
Re: thread safety of C++ standard library
- Subject: Re: thread safety of C++ standard library
- From: John Weeks <email@hidden>
- Date: Tue, 1 Dec 2009 14:30:04 -0800
Jens Alfke <email@hidden> replied:
>On Dec 1, 2009, at 1:36 PM, John Weeks wrote:
>
>> In particular, is std::sort thread-safe when working with distinct
>> containers? That is, std::sort(iterator, iterator, predicate) where
>> the
>> iterators point to different containers.
>
>I don't know for sure, but I would guess not. It's often (generally?)
>considered inappropriate to design thread-safety into low-level
>collection classes, as it adds overhead to the more common case where
>an object is being used from only one thread.
>
>For instance, the original Java 1.0 collection classes were thread-
>safe, but were soon deprecated in favor of the Java 1.2 collections
>that are not, and performance was one reason for the change.
>CoreFoundation's collections aren't thread-safe either.
>
>It's better to look at the concurrency of your larger scale object
>model and add locks at appropriate places, than to assume things get
>handled for you at a lower level. (In particular, in the case you
>describe that works on two collections, I can imagine it would be very
>hard for STL to avoid lock ordering problems; you'd need to decide on
>a policy yourself.)
Thank you, Jens.
That's all fine, and I just re-read Scott Meyers on STL thread-safety. My
problem is that I wouldn't know what to lock. Certainly not the containers;
they are different containers. The iterators? Won't new ones be generated
as sort runs? How do I lock an iterator so that std:sort respects my lock?
Perhaps the answer is simply: No, std::sort is not thread-safe, and I need
to roll my own sort.
Rush Manbert <email@hidden> replied:
>> In particular, is std::sort thread-safe when working with distinct
>> containers? That is, std::sort(iterator, iterator, predicate) where the
>> iterators point to different containers.
>
>I think that's your problem. The iterators need to point to the same
>container. The sort algorithm operates in place.
I wasn't careful with my wording. I have two threads, each calls std::sort.
Each thread has a container (a vector) to be sorted. In each thread the
iterators point to that thread's container. By "iterators point to
different containers" I was referring to the fact that the different
threads were working on different containers, not that a single call to
std:sort used iterators pointing to different containers.
Regards,
John Weeks
WaveMetrics, Inc.
Phone (503) 620-3001
Fax (503) 620-6754
email email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden