Timeline for Concurrent Operation subclass combining KVO compliance and thread safety
Current License: CC BY-SA 4.0
12 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Jan 14, 2022 at 6:03 | comment | added | Martin R | @Rob: Isn't this a question for you codereview.stackexchange.com/q/272943/35991 ? :) | |
Dec 28, 2021 at 18:07 | comment | added | lurning too koad | I've read a lot of your posts on SO and you are definitely a guru in concurrency and your help is very much appreciated! | |
Dec 28, 2021 at 18:02 | comment | added | Rob |
Because locks achieve the intuitive synchronous behavior you are looking for and are even faster than reader-writer. But if you just want to use a serial queue with sync , that works, too, though slower than reader-writer with no real benefit. But the differences are likely to be immaterial, so use whatever you are most comfortable with.
|
|
Dec 28, 2021 at 17:40 | comment | added | lurning too koad | Thank you! I think my final question is how is this locking mechanism different from, or better than, simply removing the barrier flag from the setter's queue and just using a serial queue with sync dispatching for all reads and writes? | |
Dec 28, 2021 at 16:47 | comment | added | Rob | I should have mentioned that I already added that to the end of the answer… | |
Dec 28, 2021 at 16:30 | comment | added | lurning too koad | When you say you use locks in your code, do you just mean that all of your thread-safe properties have synchronous dispatching in their setters? Can you append your answer to include an example of what this would look like? | |
Dec 28, 2021 at 8:11 | comment | added | Rob |
It’s safe to call didChangeValue outside the closure because the observer will use the getter to determine what the value actually is, and that will wait for the barrier anyway. For this reason, it’s actually important to call willChangeValue and didChangeValue outside of the synchronization because you can otherwise deadlock/crash. That having been said, I actually use locks in my code (i.e., everything synchronous) because although reader-writer feels like it should be more efficient, in practice it isn’t; it’s slower. And simple lock synchronization is easier to reason about, IMHO.
|
|
Dec 28, 2021 at 8:06 | history | edited | Rob | CC BY-SA 4.0 |
add lock example
|
Dec 28, 2021 at 6:46 | comment | added | lurning too koad |
What I don't understand is why it's safe to call didChangeValue(forKey: #keyPath(isFinished)) in the setter right after stateQueue.async(flags: .barrier) {} . If it's asynchronous, how can we be certain the KVO will be notified before the new value is applied in the closure? Wouldn't it be safer to move the KVO notifications inside the closure? And as a side note, would it really be so bad to dispatch the setter's queue synchronously?
|
|
Dec 28, 2021 at 6:12 | vote | accept | lurning too koad | ||
Dec 28, 2021 at 5:40 | history | edited | Rob | CC BY-SA 4.0 |
cancelable
|
Dec 28, 2021 at 3:01 | history | answered | Rob | CC BY-SA 4.0 |