StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
1359320
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
2
CommunityOwnedDate
CreationDate
2009-08-31T20:42:15.913
FavoriteCount
0
LastActivityDate
2009-08-31T20:42:15.913
LastEditDate
LastEditorUserId
0
OwnerUserId
165906
ParentId
1356726
PostTypeId
2
Score
3
ViewCount
0
LastEditorDisplayName
text
Body
Okay, I solved it. It can be done with just 2 semaphores, a critical section and almost no more locking than for a regular non-recursive MRSW lock (there is obviously some more CPU-time spent inside the lock because that multimap must be managed) - but it's tricky. The structure I came up with looks like this: <pre><code> // Protects everything that follows, except mWriterThreadId and mRecursiveUpgrade CRITICAL_SECTION mLock; // Semaphore to wait on for a read lock HANDLE mSemaReader; // Semaphore to wait on for a write lock HANDLE mSemaWriter; // Number of threads waiting for a write lock. int mWriterWaiting; // Number of times the writer entered the write lock. int mWriterActive; // Number of threads inside a read lock. Note that this does not include // recursive read locks. int mReaderActiveThreads; // Whether or not the current writer obtained the lock by a recursive // upgrade. Note that this member might be set outside the critical // section, so it should only be read from by the writer during his // unlock. bool mRecursiveUpgrade; // This member contains the current thread id once for each // (recursive) read lock held by the current thread in addition to an // undefined number of other thread ids which may or may not hold a // read lock, even inside the critical section (!). std::multiset<unsigned long> mReaderActive; // If there is no writer this member contains 0. // If the current thread is the writer this member contains his // thread-id. // Otherwise it can contain either of them, even inside the // critical section (!). // Also note that it might be set outside the critical section. unsigned long mWriterThreadId; </pre></code> Now, the basic idea is this: Full update of <code>mWriterWaiting</code> and <code>mWriterActive</code> for an unlock is performed by the unlocking thread. For <code>mWriterThreadId</code> and <code>mReaderActive</code> this is not possible, as the waiting thread needs to insert itself when it was released. So the rule is, that you may never access those two members except to check whether you are holding a read lock or are the current writer - specifically it may not be used to checker whether or not there are any readers / writers - for that you have to use the (somewhat redundant but necessary for this reason) <code>mReaderActiveThreads</code> and <code>mWriterActive</code>. I'm currently running some test code (which has been going on deadlock- and crash-free for 30 minutes or so) - when I'm sure that it's stable and I've cleaned up the code somewhat I'll put it on some pastebin and add a link in a comment here (just in case someone else ever needs this).
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POHow to implement a recursive MRSW lock?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USfnawothnig
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
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
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. COForgot to mention that <code>mReaderActiveThreads</code> is obviously also managed by the unlocking thread.
 singulars
 PostPostId
 PO
 UserUserId
 USfnawothnig

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.