(def my-obj (delay (SomeClass.)))

@UMPJRJU9E I think there is a risk of multiple instantiations with your implementation if init-my-obj is called on multiple threads. The reason is that the atom can be deref-ed as nil on multiple threads before any of them have set the instance.

This explains why delay is the correct approach: https://danlebrero.com/2017/06/12/delay-clojure-forgotten-concurrency-primitive/

any time you have something that derefs an atom to check the value followed by a mutation, you have a potential race

And this is also good reading material: https://purelyfunctional.tv/guide/clojure-concurrency/

not a potential race, an actual race :)

delay or defonce are two good tools for this. delay is better from an aot compilation point of view, but requires consumers to deref. defonce is easier for consumers but will be evaluated during aot, which you often don't want.

> any time you have something that derefs an atom to check the value followed by a mutation, you have a potential race Also good to know about swap-vals! if you do need both: https://clojuredocs.org/clojure.core/swap-vals!

often I combine def / delay with a wrapper function that does the deref for a friendlier combo

if you use force instead of deref it will behave as identity on non-delays

Sorry, I only posted partial code. I did think of delay but it won’t fit my case since I need to pass params while initalizing the class which might not always be the same

Can this be converted to a delay?

(def sem (atom nil))

(defn- max-instances-semaphore
  [permits]
  (or @sem
      (do (compare-and-set! sem nil (Semaphore. permits))
          @sem)))

that is building races for the semaphores

if any threads have permits, then you call that replacing the semaphore object, and those threads don't lexically capture sem, when those threads release permits they will release on the new semaphore increasing the number of permits it has

Ironic, I know, but how do I go about doing something like this? I could always pass the instantiated semaphore to the threads but was thinking if there is construct for doing something like this

you will always be better off passing

> if any threads have permits, then you call that replacing the semaphore object, and those threads don’t lexically capture sem, when those threads release permits they will release on the new semaphore increasing the number of permits it has Yeah, the goal is avoid this exactly

in general, I find it is usually better to avoid using something like a semaphore at all, and instead limit concurrency via something like a fixed size executor

The thing is we’re using integrant and I need to instantiate the Semaphore elsewhere and pass it to the function that will be invoked parallely. The function api would’ve been simpler if I could just pass the max permits instead of the actual Semaphore.

> in general, I find it is usually better to avoid using something like a semaphore at all, and instead limit concurrency via something like a fixed size executor Yup, totally agree, but in this special case, the objects go stale quite quickly (browser drivers) and a Semaphore seemed like a quick way to cap the objects.

use an executor

(my previous stance was "maybe use an executor" that explanation makes it definite)

have you considered actually using java.util.concurrent.Semaphore ?

or is that what you're using

using lots of them

generally, if you're having trouble def'ing something, maybe don't :) construct at startup and pass to those that need it

a fixed size executor will also let you adjust the number of threads doing work on the fly without creating a sequence of semaphores

(you can do that on a single semaphore as well but you may need some extra accounting)

> generally, if you’re having trouble def’ing something, maybe don’t :) construct at startup and pass to those that need it That’s what I was doing passing an instantiated Semaphore. But thought passing the max-instance-number would simplify the API than passing in a construct that would cap the number of objects (object pool, semaphore), but I guess it’s not worth it.

hiredman, it is the number of objects I want to cap and not the threads

that is largely the same thing

Anyway, there is also a pooled version using ArrayBlockingQueue

objects don't magically pop into existence, code has to create them, and that code has to run somewhere

@UEENNMX0T not directly related to your question, but I would push back on whether you need to be building and storing these caches/indexes in the atom. What would happen if state was just {:games ,,, :users ,,,} and the indexes were generated and passed around in local bindings where they would actually be needed?

ie. are multiple unrelated "threads" operating on these indexes (so you have to coordinate them) AND are the indexes used so often that they are worth it to generate and cache upfront AND are the read vs write statistics skewed towards reading (i.e. if you're swap!-ing more often than deref-ing, this could in fact be a net-negative for performance).

single threaded, single jar running on a digital ocean box, maybe like 100 players at a given time playing less than 50 games (2 player card game) so impact is low either way

i did the caching to make certain “queries” easy for myself

my point was, if impact is low, and the caches are localized - and quick to generate - it may be helpful to not try to keep them up-to-date in the atom (which complicates the code for all updates of the atom)

you can have a function that generates uid->gameid for easy queries without trying to keep it in sync when doing swaps

that makes sense. i certainly don’t know what i’m doing, i just know that the way the code is currently written is very bad lol (multiple atoms that each have to be updated individually, spaghetti code in general, etc)

cool, i’ll try that out

@UEENNMX0T BTW, your state map looks really similar to the kind of graph-like map-structures that Joinery and friends are trying to optimize for: https://github.com/cjsauer/joinery and https://github.com/cjsauer/joinery#prior-art - so if you're looking for a way to simplify your queries and mutations, perhaps you can use one of the ready-made libraries (or at least get some inspiration from their apis)

thanks for the link! i’ll check it out

Unfortunately, I found that this can exert pressure which can escape via unexpected release valves, mainly falling into the trap pointed out in Out Of The Tar Pit of passing the entire world as an extra argument

(guilty of it myself, not throwing stones)

@UQZQ9T3NV these deps are ancient:

[org.clojure/clojure "1.7.0-RC1"]
[org.clojure/clojurescript "0.0-3291" :scope "provided"]

current Clojure is 1.10.3 and ClojureScript is 1.10.891 (or at least 1.10.773 as defined in sente deps)