The last two are identical; "atomic" is the default behavior (note that it is not actually a keyword; it is specified only by the absence of nonatomic
-- atomic
was added as a keyword in recent versions of llvm/clang).
Assuming that you are @synthesizing the method implementations, atomic vs. non-atomic changes the generated code. If you are writing your own setter/getters, atomic/nonatomic/retain/assign/copy are merely advisory. (Note: @synthesize is now the default behavior in recent versions of LLVM. There is also no need to declare instance variables; they will be synthesized automatically, too, and will have an _
prepended to their name to prevent accidental direct access).
With "atomic", the synthesized setter/getter will ensure that a whole value is always returned from the getter or set by the setter, regardless of setter activity on any other thread. That is, if thread A is in the middle of the getter while thread B calls the setter, an actual viable value -- an autoreleased object, most likely -- will be returned to the caller in A.
In nonatomic
, no such guarantees are made. Thus, nonatomic
is considerably faster than "atomic".
What "atomic" does not do is make any guarantees about thread safety. If thread A is calling the getter simultaneously with thread B and C calling the setter with different values, thread A may get any one of the three values returned -- the one prior to any setters being called or either of the values passed into the setters in B and C. Likewise, the object may end up with the value from B or C, no way to tell.
Ensuring data integrity -- one of the primary challenges of multi-threaded programming -- is achieved by other means.
Adding to this:
atomicity
of a single property also cannot guarantee thread safety when multiple dependent properties are in play.
Consider:
@property(atomic, copy) NSString *firstName;
@property(atomic, copy) NSString *lastName;
@property(readonly, atomic, copy) NSString *fullName;
In this case, thread A could be renaming the object by calling setFirstName:
and then calling setLastName:
. In the meantime, thread B may call fullName
in between thread A's two calls and will receive the new first name coupled with the old last name.
To address this, you need a transactional model. I.e. some other kind of synchronization and/or exclusion that allows one to exclude access to fullName
while the dependent properties are being updated.
git log --pretty=format:"%h%x09%an%x09%ad%x09%s"
did the job. This outputs:
fbc3503 mads Thu Dec 4 07:43:27 2008 +0000 show mobile if phone is null...
ec36490 jesper Wed Nov 26 05:41:37 2008 +0000 Cleanup after [942]: Using timezon
ae62afd tobias Tue Nov 25 21:42:55 2008 +0000 Fixed #67 by adding time zone supp
164be7e mads Tue Nov 25 19:56:43 2008 +0000 fixed tests, and a 'unending appoi
93f1526 jesper Tue Nov 25 09:45:56 2008 +0000 adding time.ZONE.now as time zone
2f0f8c1 tobias Tue Nov 25 03:07:02 2008 +0000 Timezone configured in environment
a33c1dc jesper Tue Nov 25 01:26:18 2008 +0000 updated to most recent will_pagina
Inspired by stackoverflow question: "git log output like svn ls -v", i found out that I could add the exact params I needed.
To shorten the date (not showing the time) use --date=short
In case you were curious what the different options were:
%h
= abbreviated commit hash
%x09
= tab (character for code 9)
%an
= author name
%ad
= author date (format respects --date= option)
%s
= subject
From kernel.org/pub/software/scm/git/docs/git-log.html (PRETTY FORMATS section) by comment of Vivek.
Best Answer
In Xcode 6.1.1, you can view the NSLog output by doing the following. However, I'm not sure if it lets you see logs from too far back in time. I've only seen it go back up to a couple hours.
In any case, here are the steps: