Clojurians Log v2

I had an idea for a deftype improvement (https://ask.clojure.org/index.php/10369/add-atomic-field-updaters-to-deftype) which may be of interest to people here, but also may be pretty niche (the small set of people who use deftype, who use volatile-mutable, who want atomic updates)

@hiredman what about VarHandles?

those sort of subsume AFUpdaters, adding capabilities

Yeah looks interesting I hadn't seen them before, the api there is certainly clunkier to use from clojure(all those java varargs)

they are all signature polymorphic calls, which Clojure can't call fully

https://download.java.net/java/early_access/jdk16/docs/api/java.base/java/lang/invoke/MethodHandle.html#sigpoly

Seems like a huge hassle then, I just want to cas on type fields without having to do weird hacks to construct the updater once in a context that can access the field

@hiredman why CAS on the type fields, rather than reference an atom?

I could imagine it's memory overhead, just trying air assumptions

Exactly that

Building a new reference type

I want them to be as lean as possible

Memory overhead both just in terms of more objects but also in terms of pointer chasing

https://gist.github.com/6c111db73ac020e1a234e0361e2e067a is an example of the hack I have now (adding a 0-arg invoke method to build the updater and return it)

and I totally forgot about the double layers function call hacks because the repl really likes to invoke all functions using apply

I like that deftypes don't allow a set! to escape into a closure. Care has to be taken with both AFUs and VarHandles to not let them leak out

closure, not clojure 😅

This question would be much rather if you wrote it as "I have problem X, one possible solution is Y" rather than "Add Y" (Ghadi's questions below signify perhaps several possible other solutions as well)

The question does hint at all at why you want this or how it would be used with which we could compare possible solutions

AtomicReferenceFieldUpdater only lets you do safe operations(same operations as on an atom + lazySet + weakCompareAndSet) on the field

I thought that this: > I have been playing with implementing some alternative concurrency constructs in Clojure which ends up using a lot of atomic reference fields. It is easy enough to just wrap an atom around all these things, but that introduces an extra object and layer of indirection. was that

should it just not mention AtomicReferenceFieldUpdater at all and just say "the jvm lighter weight ways to do cas on fields, it be would be nice to expose"?