Re: thread safety of C++ standard library
Re: thread safety of C++ standard library
- Subject: Re: thread safety of C++ standard library
- From: Clark Cox <email@hidden>
- Date: Tue, 1 Dec 2009 14:33:14 -0800
On Tue, Dec 1, 2009 at 2:30 PM, John Weeks <email@hidden> wrote:
> 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.
OK. That makes more sense. That should be fine; two unrelated sort
calls, sorting two unrelated containers shouldn't pose any
thread-safety issues (assuming that no *other* threads are accessing
those containers,or their iterators, in any way).
--
Clark S. Cox III
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