StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
19431778
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
9
CommunityOwnedDate
CreationDate
2013-10-17T16:06:41.097
FavoriteCount
0
LastActivityDate
2016-03-30T03:01:18.213
LastEditDate
2017-05-23T12:17:59.863
LastEditorUserId
-1
OwnerUserId
1991609
ParentId
15392726
PostTypeId
2
Score
9
ViewCount
0
LastEditorDisplayName
text
Body
Generally, <code>@synchronized</code> guarantees thread safety, but only when used correctly. It is also safe to acquire the lock recursively, albeit with limitations I detail in my answer <a href="https://stackoverflow.com/questions/10163456/locked-up-waiting-for-synchronized/19429880#19429880">here</a>. There are several common ways to use <code>@synchronized</code> wrong. These are the most common: Using <code>@synchronized</code> to ensure atomic object creation. <pre><code>- (NSObject *)foo { @synchronized(_foo) { if (!_foo) { _foo = [[NSObject alloc] init]; } return _foo; } } </code></pre> Because <code>_foo</code> will be nil when the lock is first acquired, no locking will occur and multiple threads can potentially create their own <code>_foo</code> before the first completes. Using <code>@synchronized</code> to lock on a new object each time. <pre><code>- (void)foo { @synchronized([[NSObject alloc] init]) { [self bar]; } } </code></pre> I've seen this code quite a bit, as well as the C# equivalent <code>lock(new object()) {..}</code>. Since it attempts to lock on a new object each time, it will always be allowed into the critical section of code. This is not some kind of code magic. It does absolutely nothing to ensure thread safety. Lastly, locking on <code>self</code>. <pre><code>- (void)foo { @synchronized(self) { [self bar]; } } </code></pre> While not by itself a problem, if your code uses any external code or is itself a library, it can be an issue. While internally the object is known as <code>self</code>, it externally has a variable name. If the external code calls <code>@synchronized(_yourObject) {...}</code> and you call <code>@synchronized(self) {...}</code>, you may find yourself in deadlock. It is best to create an internal object to lock upon that is not exposed outside of your object. Adding <code>_lockObject = [[NSObject alloc] init];</code> inside your init function is cheap, easy, and safe. EDIT: I still get asked questions about this post, so here is an example of why it is a bad idea to use <code>@synchronized(self)</code> in practice. <pre><code>@interface Foo : NSObject - (void)doSomething; @end @implementation Foo - (void)doSomething { sleep(1); @synchronized(self) { NSLog(@"Critical Section."); } } // Elsewhere in your code dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0); Foo *foo = [[Foo alloc] init]; NSObject *lock = [[NSObject alloc] init]; dispatch_async(queue, ^{ for (int i=0; i<100; i++) { @synchronized(lock) { [foo doSomething]; } NSLog(@"Background pass %d complete.", i); } }); for (int i=0; i<100; i++) { @synchronized(foo) { @synchronized(lock) { [foo doSomething]; } } NSLog(@"Foreground pass %d complete.", i); } </code></pre> It should be obvious to see why this happens. Locking on <code>foo</code> and <code>lock</code> are called in different orders on the foreground VS background threads. It's easy to say that this is bad practice, but if <code>Foo</code> is a library, the user is unlikely to know that the code contains a lock. 
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. PODoes @synchronized guarantees for thread safety or not?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USCommunity
UserOwnerUserId
1. USHolly
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. This table or related slice is empty.
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.