On Sep 22, 12:07 pm, MikeM <[EMAIL PROTECTED]> wrote:
> > On second thought, maybe Agents will work, if one can enforce the
> > ordering of updates.
>
> "Actions dispatched to an agent from another single agent or thread
> will occur in the order they were sent" (from clojure.org/agents) -
> seems like this may be helpful,
It also says:
"If during the function execution any other dispatches are made
(directly or indirectly), they will be held until after the state of
the Agent has been changed."
That means that if, as a result of an update, some agent sends
messages to others, they will definitely arrive after the original
agent's state has been changed.
> but since updates can occur from
> multiple threads (the agent thread pool), it seems that the agent
> cells implementation must explicitly enforce update ordering to match
> the dependency relationship.
I don't know anything about Cells, but if it has global time ordering
it might not be a good fit for multithreading, and not for agents.
Agents provide the useful multithreaded guarantees above, if you can
architect with the concurrency multithreading implies.
The difference is, if agent A notifies B and C, and B notifies C, then
a change to A will send actions to B and C, and B will subsequently
send to C, but A's message to C and B's message to C can arrive in any
order. Once you are ok with that, you can do multithreaded reactive
programming.
I've often thought of providing change notification queues on the
agents themselves, letting Clojure do reactive programming right out
of the box.
Rich
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
