True, but very bad practice. Better to check after the swap! completes to
see if it was successful and then send the notifications.
If you do the notifications within the swap! function, you are holding the
atom for longer than need be and increasing the chance of contention.
Contention means that the other contenders keep looping until they are able
to acquire the atom. And that means a potentially significant increase in
overhead. compare-and-set! and swap! only work well when the number of
contenders is small, and a slow swap! function increases the chance of
having other contenders more frequently.
When contention is high, atoms are a poor choice. That's when you switch
over to something like async.core. :-)
On Mon, Feb 1, 2016 at 10:48 AM, Jeremy Vuillermet <
jeremy.vuiller...@gmail.com> wrote:
> That's very clear thank you. Some follow up questions:
>
> In my case, I still need to notify every player that the resource is not
> available anymore and that is a side effect.
> Should I just make it idempotent so it doesn't matter if it's called more
> than once.
>
> If I check for the resource within the function passed to swap! and do my
> side effect only when it's available, It should not happen more than once,
> right ?
>
> On Mon, Feb 1, 2016 at 3:27 PM, William la Forge <laforg...@gmail.com>
> wrote:
>
>> The easy way is the big atom approach. Put the entire structure in an
>> atom and use swap! to make updates.
>>
>> First, the function passed to swap! should be free of side-effects, as
>> swap! may need to call it more than once in the case of a collision.
>>
>> Second, within the function passed to swap! is where you check to see if
>> the resource is available. If it is, you take it. Otherwise not.
>>
>> Now as for suitability. Note that the function passed to swap! must
>> return the replacement value of your immutable structure. So it important
>> that your structure records who got the resource being requested. And it
>> looks like your structure handles that.
>>
>> No need to use compare and set. The swap! function is good enough. It is
>> really a convenience function layered over compare-and-set.
>> Sometimes swap! is not powerful enough, which is when you use
>> compare-and-set.
>>
>>
>> On Monday, February 1, 2016 at 7:29:39 AM UTC-5, Jeremy Vuillermet wrote:
>>>
>>> Hello,
>>>
>>> I'm making a game where players can choose a box in a grid to discover
>>> what's behind it.
>>>
>>> My data structure is an atom with {:grid-size 5, :picks {5 "player1}}
>>> where 5 is the box position in the grid.
>>>
>>> How can I be sure that two players can't pick the same box. From my
>>> understanding, checking the box and then swaping if the box is free is not
>>> enough.
>>> So I guessed I should use compare and set but I only understand how it
>>> works with simple atom like (atom 1).
>>>
>>> 2 questions then : Is my data structure adapted for that ?
>>>
>>> How to compare and set only for a nested path like [:picks 5] ?
>>>
>>> Thanks
>>>
>> --
>> 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
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/clojure/X59ZTmPQhZ0/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> 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
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/X59ZTmPQhZ0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
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
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
