Move properties to nonatomic

[joeljfischer]

Not having any sort of threading is a separate (larger) issue, but that every property is atomic is going to slow the library down quite a bit. Most (or all, if we do our threading properly) things should be nonatomic.

[joeljfischer]

To support my argument of dropping atomicity for properties, this is Mike Ash's thoughts, taken from a blog post on locking and Swift.

Atomic properties are not often useful. The problem is that, unlike many other useful properties of code, atomicity doesn't compose. For example, if function f doesn't leak memory, and function g doesn't leak memory, then function h that just calls f and g also doesn't leak memory. The same is not true of atomicity. For an example, imagine you have a set of atomic, thread-safe Account classes:

let checkingAccount = Account(amount: 100)
let savingsAccount = Account(amount: 0)

Now you move the money to savings:

checkingAccount.withDraw(100)
savingsAccount.deposit(100)

In another thread, you total up the balance and tell the user:

println("Your total balance is: \(checkingAccount.amount + savingsAccount.amount)")

If this runs at just the wrong time, it will print zero instead of 100, despite the fact that the Account objects themselves are fully atomic and the user had a balance of 100 the whole time. Because of this, it's usually better to build entire subsystems to be atomic, rather than individual properties.

There are rare cases where atomic properties are useful, because it really is a standalone thing that just needs to be thread safe.

Add to that the fact that every accessor and setter is essentially running in a recursive blocking lock, which is not cheap computationally. They really should be largely (or wholly) moved to non-atomic, and the entire proxy should be rebuilt with thread safety in mind.

[justinjdickow]

Changing properties to non atomic will likely require a full re-validation of the iOS library so we're marking this as future and epic for now

[asm09fsu]

Merged into develop.