4 ms·

I tried Realm for an OS X desktop app a few months ago. I initially liked it, but was surprised when I discovered the threading requirements (one realm instan

by ttcbj 10y ago

I tried Realm for an OS X desktop app a few months ago. I initially liked it, but was surprised when I discovered the threading requirements (one realm instance per thread, cannot pass realm-based objects across threads). 1) When I see that a library has a note about threading, I generally expect that it will either be "its thread safe" or "these operations are not thread safe and you need your own synchronization." I think having no ability to share realms/objects across threads is really unusual, and it would be better if the docs made that requirement clearer at the beginning. 2) My use case was reasonably simple - background thread A listens for messages about some expensive work to do, it updates the UI thread with the work, and then it spawns thread B to do that expensive work and keeps listening, thread B updates the worklist on the UI thread on completion. Based on my understanding of realm, I was going to have 3 copies of each object, one on each thread. Traditionally, I would expect one in-memory copy, with the threads using synchronized methods to modify the data. Then, when thread B completes, it just updates its work item and then notifies the UI thread to re-render. Maybe I misunderstood it, or there is some really simple architecture to handle this issue, but that is how it seemed to me from the documentation.

jpsim 10y ago
(JP from Realm here) Realm's transactions are entirely ACID, and all transactions are thread safe. This means you can't get "faults" like you would in Core Data if one thread deletes an object being accessed in another. On the flip side of this, it makes it difficult to share mutable object graphs across threads, mostly because then you'd need to know which Realm and which object is at what version of the db. Realm's underlying db engine supports this, but it's difficult to expose/enforce at the API level. We have some designs in mind to allow scoping around passing objects between threads (see #3136[0]), and some other ideas for passing immutable Realms across threads, so you can expect to see some improvements there in the future. About improving our documentation around threading, we're always open to feedback. I'd appreciate if you could read through the "Threading" section of our docs[1] and share how you think it could be improved. [0]: https://github.com/realm/realm-cocoa/issues/3136 https://github.com/realm/realm-cocoa/issues/3136 [1]: https://realm.io/docs/swift/latest#threading https://realm.io/docs/swift/latest#threading
astigsen 10y ago
> having no ability to share realms/objects across threads is really unusual, and it would be better if the docs made that requirement clearer at the beginning. Good point that we should be more explicit about threading model of Realm and its benefits. Realms and their objects can be shared across threads (and processes), you just have to be explicit about it (by having each thread get its own instances of the given objects/realms). The huge benefit you get from this, is that you never have to worry about locking or any other concurrency issues. All threads will always have a consistent view of the data, it will only update to reflect changes done by other threads at safe points in your code (like between events, where you are not in the process of using the data). > Based on my understanding of realm, I was going to have 3 copies of each object, one on each thread. You don't need 3 copies, only three instances. That way each thread will have its own instance (and as such not be affected by changes on other threads), but they will all point to the same underlying data. > I would expect one in-memory copy, with the threads using synchronized methods to modify the data. Then, when thread B completes, it just updates its work item and then notifies the UI thread to re-render. With realm you don't even have to do that. You can let thread B modify the object, and then the UI thread can just watch its own instance of that same object and be notified when it changes, it can then update the UI. All perfectly safe without any need for manual synchronization between the threads.

by ttcbj 10y ago

jpsim 10y ago

(JP from Realm here) Realm's transactions are entirely ACID, and all transactions are thread safe. This means you can't get "faults" like you would in Core Data if one thread deletes an object being accessed in another. On the flip side of this, it makes it difficult to share mutable object graphs across threads, mostly because then you'd need to know which Realm and which object is at what version of the db. Realm's underlying db engine supports this, but it's difficult to expose/enforce at the API level. We have some designs in mind to allow scoping around passing objects between threads (see #3136[0]), and some other ideas for passing immutable Realms across threads, so you can expect to see some improvements there in the future. About improving our documentation around threading, we're always open to feedback. I'd appreciate if you could read through the "Threading" section of our docs[1] and share how you think it could be improved. [0]: https://github.com/realm/realm-cocoa/issues/3136 https://github.com/realm/realm-cocoa/issues/3136 [1]: https://realm.io/docs/swift/latest#threading https://realm.io/docs/swift/latest#threading

astigsen 10y ago

> having no ability to share realms/objects across threads is really unusual, and it would be better if the docs made that requirement clearer at the beginning. Good point that we should be more explicit about threading model of Realm and its benefits. Realms and their objects can be shared across threads (and processes), you just have to be explicit about it (by having each thread get its own instances of the given objects/realms). The huge benefit you get from this, is that you never have to worry about locking or any other concurrency issues. All threads will always have a consistent view of the data, it will only update to reflect changes done by other threads at safe points in your code (like between events, where you are not in the process of using the data). > Based on my understanding of realm, I was going to have 3 copies of each object, one on each thread. You don't need 3 copies, only three instances. That way each thread will have its own instance (and as such not be affected by changes on other threads), but they will all point to the same underlying data. > I would expect one in-memory copy, with the threads using synchronized methods to modify the data. Then, when thread B completes, it just updates its work item and then notifies the UI thread to re-render. With realm you don't even have to do that. You can let thread B modify the object, and then the UI thread can just watch its own instance of that same object and be notified when it changes, it can then update the UI. All perfectly safe without any need for manual synchronization between the threads.