Hmm, lurer på om jeg ikke skal forsøke det gode gamle #clojure-europe trikset: God morgen!

God morgen!

Good morning!

Hva er målet egentlig? Ser ut som om #clojure-europe har lykkes i å få sin kanal til å hovedsakelig bestå av “good morning” 😁

For meg har det gitt en veldig hyggelig følelse av tilhørighet. Det er også et sted der jeg føler at jeg kan stille dumme/rare spørsmål blant venner som antar at slike spørsmål er stilt i beste hensikt.

Men, ja, som oftest er det bare masse good morning, men i blant blir det noe fint ut av det.

Jada, fint tiltak!

Innser at kommentaren min fremstår mer surmaget enn den var ment som

Morn!

God morgen, ja 😄

Morn 😁

Ok, så her kommer et sånt spørsmål, eller noe. Gitt at vi er i et multithreaded miljø:

(defn sideffecting-expensive-operation [label]...)

(defn setup [some-atom label]
  (let [r (sideffecting-expensive-operation label)]
    (swap! some-atom assoc label r)))

(defn setup [some-atom label]
 (let [r (delay (sideffecting-expensive-operation label))]
    (swap! some-atom (fn [m] (if (contains? m label) m (assoc m label (force r))))))

Grunnen til at vi ikke kan gjøre:

(defn setup [some-atom label]
   (swap! some-atom (fn [m] (if (contains? m label) m (assoc m label (sideffecting-expensive-operation label))))))

Kan du memoize sideffecting-expensive-operation? Det hindrer ikke at den kan bli kalt flere ganger samtidig hvis setup kalles flere ganger samtidig, riktignok.

Jeg lurte litt på det….

Hvis du vil garantere at sideffecting-expensive-operation aldri kjører samtidig for samme verdi av label kan du bruke locking:https://clojuredocs.org/clojure.core/locking

Tilsvarer synchronized i Java.

Ein kan nytta fnil...?

(defn setup [some-atom label]
  (let [r (delay (sideffecting-expensive-operation label))]
     (swap! some-atom update label (fnil force r))))

Sant nok, men det var delay/`force` jeg ville unngå

Kva med locking som msolli føreslo?

(defn setup [some-atom label]
  (locking some-atom
    (when (nil? (get @some-atom label))
      (swap! some-atom assoc label (sideffecting-expensive-operation label)))
    @some-atom))

That's what I proposed. Cons is you now lock on the whole atom, limiting concurrency more than necessary. But it might well be acceptable...

Kan du ha et atom med future's i?

(swap! some-atom assoc label (delay (sideffecting-expensive-operation label)))

og så deref'e den ved bruk?

Hvis du er bekymret for at den blir assoc'et på flere ganger, så kan du trygt gjøre

(swap! some-atom update label #(or % (delay (sideffecting-expensive-operation label))))

☝️ denne tåler å bli kjørt mange ganger

Dette var løsningen vi havnet på hos Norled, i hvert fall, etter en del diskusjoner her på Slack'en.

Er det viktig her om man bruker future eller delay? Future betyr kanskje at man starter å regne ut svaret ved første kall til swap!, uten å vente på første deref?

i så fall vil du unngå det

hvis du vil starte prosessen med det samme, så er det bedre å gjøre noe slikt:

(-> (swap! some-atom update label #(or % (delay (sideffecting-expensive-operation label))))
    (get label)
    deref)

for da er du sikker på at du er ferdig med Compare and Swap når du sparker den i gang 🙂

ahhh, ja. Sant. Fint å slippe race conditions.

Kjempefint spørsmål, Erik. Har lurt på det samme før selv.

Jeg synes primitivene i Clojure er kjempebra, men det tar tid å lære seg å sette dem sammen på en god måte