On Apr 15, 4:12 pm, Robert Feldt <robert.fe...@gmail.com> wrote:
> Although I understand each of the concurrency "primitives"/systems
> (stm, agents, atoms, dynvars) in isolation I find it harder to choose
> wisely between them when designing/implementing specific algorithms
> and programs.
>
> Do you have any advice/tips for how to choose between Clojure's
> different concurrency constructs?
> How do you decide which construct to use for a particular algorithm/
> program?
>
> To me it often feels as if there is no clear-cut, best solution.
> Rather several possibilities would all work ok and I'm not sure how to
> trade-off performance with maintainability/understandability.
>
> As an example I recently implemented an Evolutionary Computation
> framework where a population of individuals are evaluated and then
> operated on with different genetic operators. This is an
> "embarassingly parallel" algorithm where most anything can go on in
> parallel. But do we need to keep the individuals in a ref so we can
> control the size of the population (maybe handy but not really needed
> for EC performance), should operators be agents so that we can have as
> many of them as there are cores etc. etc.
>
> Any advice/links/pointers on designing with a more complex set of
> concurrency primitives appreciated. I don't feel previous material/
> books I've read (written in a mainly-pre-concurrency era (at least
> compared to Clojure)) gives enough since concurrency were not really
> an essential elements of the languages then in vogue.
>
> Something like "Design Patterns" for Clojure concurrency would be
> nice... ;)
> (Googling I found this:http://www.cs.wustl.edu/~schmidt/POSA/POSA4/
> Someone read it? Relevant?)
I haven't tried STM yet. I am writing a simple board game program that
uses atoms as the means of concurrency control. I have two compound
types achiTask and achiGame defined something like the following (note
the field directors):
=============================================
(defn createAchiGame [gameId firstPlayer world gameMoveHistory
finished directors]
{
:tag ::achiGame,
:gameId gameId,
:firstPlayer firstPlayer,
:world world,
:gameMoveHistory gameMoveHistory
:finished finished
:directors directors})
(defn createAchiTask [ ]
(let
[firstPlayer -northPlayer-
world (createNewWorld firstPlayer)
gameMoveHistory (vector)
finished false
northDirector (createDirector -northPlayer- -computer-)
southDirector (createDirector -southPlayer- -human-)
directors {-northPlayer- northDirector, -southPlayer-
southDirector}
achiGame (createAchiGame 0 firstPlayer world gameMoveHistory
finished directors)
achiGameHandle (atom achiGame)
achiTaskAgents ...
achiFrame ...
achiGamePanel #^JPanel ...
newWindowButton ...
achiTask (hash-map :tag ::achiTask,
:achiGameHandle achiGameHandle,
:achiTaskAgents achiTaskAgents,
:achiFrame achiFrame,
:achiGamePanel achiGamePanel
:newWindowButton newWindowButton)
=============================================
I think that the field directors really belongs in the achiTask type
and not in the achiGame type. But, by putting "directors" in achiGame,
I seem to avoid the need for having STM to control concurrency and
just use swapping the atom achiGameHandle when the achiGame changes or
the directors change.
I am considering whether this is a good idea or not. Offhand, I would
say it is not a good idea since it is warping the application design
in order to simplify the coding for concurrency. But, I am going to
stick with this approach and finish my board game and then see how I
can use STM to advantage. Like you, I am trying to understand how to
code to meet concurrency requirements using the tools Clojure
provides. At this point, I am concentrating on "atom" and seeing what
I can do with it.
--~--~---------~--~----~------------~-------~--~----~
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
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
-~----------~----~----~----~------~----~------~--~---
