> object-oriented programming makes for terribly inefficient data structures that cannot handle threading very well.
The best approach I have seen to address this is the idea of transactional object as it is done in Realm (yes, the mobile database).
The idea that objects can freely be accessed on any thread without locks, with all changes protected by transactions, is so freeing, and the internal representation that Realm uses for the objects is apparently far more efficient than how they would natively be represented.
I really wonder why we are not seeing more of these kinds of transactional data structures. Seems like a natural next step for object oriented programming now that everything is turning multi-core.
That's sort of like software transactional memory, which has a reputation for being slow. However, limiting transactions to one object at a time may avoid most of the overhead; in fact I suspect it would often perform better than locking. On the other hand, that sounds tough to reason about… do you just always use persistent (immutable) data structures? Because those have quite a bit of overhead (if you don't need persistence anyway for some reason). If not, how do you prevent one thread from seeing another thread's transaction in progress?
> how do you prevent one thread from seeing another thread's transaction in progress?
In Realm this is done by each thread having its own immutable snapshot of the data which is only advanced to the latest state at very specific "safe" points in the code. The result of this is that data never changes underneath you (i.e. You never see changes from transactions in progress. You only see after they have been atomically applied).
I guess that you could think of Realm as an immutable data structure (as it is immutable outside of very specific conditions like inside write transactions and a state refreshes at "safe" points in the code. But the experience is totally different. It basically feels like you have plain old (mutable) objects, but they can be safely shared between threads without any of the overhead (mentally and performace wise) of locks.
My point wasn't about memory usage, it was about development cost. The transactional behaviour emerges by default from use of immutable structures.
Any transactional system will have memory performance characteristics that are very similar to using immutable structures, if not worse, so your point was, well, pointless.
The best approach I have seen to address this is the idea of transactional object as it is done in Realm (yes, the mobile database).
The idea that objects can freely be accessed on any thread without locks, with all changes protected by transactions, is so freeing, and the internal representation that Realm uses for the objects is apparently far more efficient than how they would natively be represented.
I really wonder why we are not seeing more of these kinds of transactional data structures. Seems like a natural next step for object oriented programming now that everything is turning multi-core.