Hi Rich, > > First, and foremost, it creates interaction relationships between > transactions that otherwise have no overlap. You see this in the > memory blowup during overlapping transactions. This rubs against a > design objective in Clojure's STM to absolutely minimize transactional > overlap and interaction.
Fair enough. > > Second, you do a lot of work in createNewTransaction (get a new > timestamp, modify existing head, make new transaction the head). How > is that made consistent? You really need a lock, and at that point > have moved to a much heavier contention point than in the current > Clojure STM. I don't think that's right. I can do most of it with CAS. I need to the list pointer afterwards but only 1 thread ever sets it and it's never read. Well, it's been running tests an i7 without showing any issues so far. > > Third, I'm wary of such extensive use of WeakReferences. That may just > be conservatism on my part. It's a fair point, you have to be careful with WeakReferences, they have a habit of disappearing between uses. > > I had considered and implemented similar designs in the early stages > of developing Clojure's STM, and, while they have some appeal, I think > these 3 points will eventually cause pain in practice. Thanks, I thought you would have considered it but wasn't sure why you went the direction you did. I think it just shows how lazy I am in not wanting to write the code to manage the lists. I appreciate your response. Regards, Peter -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
