Fork me on GitHub
#clojure-dev
<
2021-03-23
>
hiredman18:03:25

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)

alexmiller21:03:33

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)

alexmiller21:03:48

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

hiredman21:03:52

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

hiredman21:03:39

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"?

alexmiller01:03:05

Mentioning ideas is fine, just start with what you’re trying to do

alexmiller01:03:53

What problem is the alternative concurrency construct trying to solve? Why don’t the existing suffice?

ghadi19:03:58

@hiredman what about VarHandles?

ghadi19:03:43

those sort of subsume AFUpdaters, adding capabilities

hiredman19:03:07

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

ghadi19:03:54

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

hiredman19:03:24

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

ghadi19:03:19

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

ghadi19:03:44

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

hiredman19:03:08

Exactly that

hiredman19:03:28

Building a new reference type

hiredman19:03:08

I want them to be as lean as possible

hiredman19:03:47

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

1
hiredman20:03:42

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)

hiredman20:03:27

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

ghadi20:03:39

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

ghadi20:03:24

closure, not clojure 😅

hiredman21:03:57

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