4 ms·
I'm generally against any complex lock-free data structures, because they're extremely difficult to prove to be reliable (and I mean prove in ACL2 sense of proo
by cliff 18y ago
I'm generally against any complex lock-free data structures, because they're extremely difficult to prove to be reliable (and I mean prove in ACL2 sense of proof).
Have you tried any of the garbage collection libraries for C++? I've never used them for any of my projects, but I currently work in the mobile industry and they would potentially solve two problems. One being the concurrency issue, but then also memory fragmentation. (Windows Mobile 6 allows 32 MB of memory max per process, so this is a big one for mobile)
I know they can cause a lot of cache misses, but it seems like all but the most primitive of low end devices would run into a problem with it in most situations at this point.
- pmjordan 18y agoIndeed, lock-free data structures can be a massive pain to implement. Clojure solves this problem, quite elegantly in my opinion, by making the data structures themselves immutable, any operations yield a new instance of the data structure (with shared substructure of course). You can then update references to the data structure with the new data structure; in Clojure the idiomatic way to do this is using STM transactions, but you could do it with atomic updates or locks in any other language. Presumably, this won't scale especially well with many writers, at least not for trees and hash tables. I surveyed the GC-on-C++ situation a couple of years ago, and nothing was realistically that useful for concurrent applications. Definitely nothing anywhere near as sophisticated as, say, the JVM's garbage collector.