StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
20571338
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2013-12-13T16:31:02.180
FavoriteCount
0
LastActivityDate
2013-12-13T16:31:02.180
LastEditDate
LastEditorUserId
0
OwnerUserId
576911
ParentId
4037853
PostTypeId
2
Score
4
ViewCount
0
LastEditorDisplayName
text
Body
Old question, new answer: Imho, a better way to deal with the dead-lock problem of the original copy assignment operator is: <pre><code> A& operator=(const A& other) { if (this!=&other) { std::unique_lock<std::mutex> _mylock(mtx, std::defer_lock), _otherlock(other.mtx, std::defer_lock); std::lock(_mylock, _otherlock); i = other.i; } return *this; } </code></pre> I.e. use <code>std::lock(L1, L2)</code> to simultaneously lock the two mutexes without fear of deadlock. This is likely to be higher performance than the copy/swap idiom, especially if the member data consists of <code>std::vector</code>, <code>std::string</code>, or types that contain vectors and/or strings. In C++1y (we hope y is 4), there is a new <code><shared_mutex></code> header providing read/write lock capability which may provide a performance boost (performance testing would be necessary for specific use cases to confirm that). Here is how it would be used: <pre><code>#include <mutex> #include <shared_mutex> class A { private: int i; mutable std::shared_mutex mtx; public: A() : i(), mtx() { } A(const A& other) : i(), mtx() { std::shared_lock<std::shared_mutex> _lock(other.mtx); i = other.i; } A& operator=(const A& other) { if (this!=&other) { std::unique_lock<std::shared_mutex> _mylock(mtx, std::defer_lock); std::shared_lock<std::shared_mutex> _otherlock(other.mtx, std::defer_lock); std::lock(_mylock, _otherlock); i = other.i; } return *this; } int get() const { std::shared_lock<std::shared_mutex> _mylock(mtx); return i; } }; </code></pre> I.e. this is very similar to the original code (modified to use <code>std::lock</code> as I've done above). But the member mutex type is now <code>std::shared_mutex</code> instead of <code>std::mutex</code>. And when protecting a <code>const A</code> (and assuming no mutable members besides the mutex), one need only lock the mutex in "shared mode". This is easily done using <code>shared_lock<shared_mutex></code>. When you need to lock the mutex in "exclusive mode", you can use <code>unique_lock<shared_mutex></code>, or <code>lock_guard<shared_mutex></code> as appropriate, and in the same manner as you would have used this facilities with <code>std::mutex</code>. In particular note that now many threads can simultaneously copy construct from the same <code>A</code>, or even copy assign from the same <code>A</code>. But only one thread can still copy assign to the same <code>A</code> at a time.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POThread-safe copy constructor/assignment operator
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USHoward Hinnant
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POThread-safe copy constructor/assignment operator
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.