StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
6433980
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2011-06-22T01:40:10.647
FavoriteCount
0
LastActivityDate
2011-06-22T13:41:48.510
LastEditDate
2011-06-22T13:41:48.510
LastEditorUserId
158779
OwnerUserId
158779
ParentId
6433374
PostTypeId
2
Score
4
ViewCount
0
LastEditorDisplayName
text
Body
You have a few options. <ul> <li>Do nothing.</li> <li>Make the class immutable.</li> <li>Use a plain old <code>lock</code>.</li> <li>Mark the fields as <code>volatile</code>.</li> <li>Use the <code>Interlocked</code> set of methods.</li> </ul> Since reads and writes to a <code>bool</code> are guaranteed to be atomic then you may not need to do anything. This will very much depend on the nature of the way your class is going to be used. Atomicity does not equal thread-safety. It is only one aspect of it. The ideal solution is to make your class immutable. Immutable classes are generally thread-safe because they cannot be modified by other threads (or at all for that matter). Sometimes this just is not feasible though. My next preference on the list is a plain old <code>lock</code>. The overhead of acquiring and releasing is very minimal. In fact, I think you will find that a <code>lock</code> will beat out a <code>ReaderWriterLockSlim</code> in most situations especially if all you are doing is reading/writing a variable. My own personal tests indicate that the overhead of RWLS is about 5x slower than a <code>lock</code>. So unless the read operations are unusually long and that they significantly outnumber write operations then RWLS will not help. If you are concerned about lock overhead then by all means mark the fields as <code>volatile</code>. Just remember that <code>volatile</code> is not a magic bullet that solves all concurrency issues. It is not intended as a replacement for <code>lock</code>.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POIs locking access to a bool required or is it Overkill
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USBrian Gideon
UserOwnerUserId
1. USBrian Gideon
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POIs locking access to a bool required or is it Overkill
 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
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTAcceptedByOriginator
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.