Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move properties to nonatomic #49

Closed
joeljfischer opened this issue Jan 22, 2015 · 3 comments

Comments

@joeljfischer
Copy link
Member

commented Jan 22, 2015

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

This comment has been minimized.

Copy link
Member Author

commented Feb 10, 2015

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 justinjdickow added the epic label Jul 31, 2015

@justinjdickow justinjdickow added this to the Future milestone Jul 31, 2015

@justinjdickow

This comment has been minimized.

Copy link
Contributor

commented Jul 31, 2015

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

@joeljfischer joeljfischer modified the milestones: 5.0.0, Future Sep 16, 2016

@joeljfischer joeljfischer changed the title Every property is atomic, but there doesn't seem to be any threading Move properties to nonatomic Sep 16, 2016

@asm09fsu

This comment has been minimized.

Copy link
Contributor

commented Jan 18, 2017

Merged into develop.

@asm09fsu asm09fsu closed this Jan 18, 2017

@asm09fsu asm09fsu moved this from Features Backlog to Done in v5.0.0 Mar 7, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
3 participants
You can’t perform that action at this time.