Newbie: General question about concurrency in Clojure

2011-03-09 Thread Nick Wiedenbrueck
I'm still getting started with Clojure and I'm wondering about how one
should generally go about concurrency and how transparent concurrency
is in Clojure. So, to me there would be two approaches:

A) Be aware of the parts of your system that will be concurrent and
only within these parts write concurrent code using reference types
and so on. My question here would be, how much a developer has to
scratch his head about concurrency. Agreed, it's much easier than
using locks like in Java, but still I have to think about what should
be a ref, what should be an agent and how to set up transactions.

B) Write concurrent code where you can, even the (smallest) parts of
your system which aren't necissarily inherently concurrent. The
question here is, if handling concurrency in Clojure is simple enough
to go about it this way, or if it would be much less effort to write
non-concurrent code.

So, in general I think the question is, how transparent concurrency is
in Clojure. The ultimate goal would be to just write code, that is
concurrent, but to not have to think to much about it.

If you like, you could also compare Clojure's approach to actor based
models.

-- 
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


Re: Newbie: General question about concurrency in Clojure

2011-03-09 Thread Joost
On Mar 9, 9:26 am, Nick Wiedenbrueck
 wrote:
> I'm still getting started with Clojure and I'm wondering about how one
> should generally go about concurrency and how transparent concurrency
> is in Clojure. So, to me there would be two approaches:
>
> A) Be aware of the parts of your system that will be concurrent and
> only within these parts write concurrent code using reference types
> and so on.

Basically, yes. But note that any code that doesn't use atoms, refs
and other mutable stuff "is concurrent" by itself. The ref types are
the ones that require some thought.

As a rough rule of thumb, this means you want to keep the number of
reference objects down.

> My question here would be, how much a developer has to
> scratch his head about concurrency. Agreed, it's much easier than
> using locks like in Java, but still I have to think about what should
> be a ref, what should be an agent and how to set up transactions.

You always have this problem. But really, if you're new to clojure,
you don't need refs nearly as much as you probably think right now.

> B) Write concurrent code where you can, even the (smallest) parts of
> your system which aren't necissarily inherently concurrent. The
> question here is, if handling concurrency in Clojure is simple enough
> to go about it this way, or if it would be much less effort to write
> non-concurrent code.
>
> So, in general I think the question is, how transparent concurrency is
> in Clojure. The ultimate goal would be to just write code, that is
> concurrent, but to not have to think to much about it.

Again, anything that doesn't use mutable objects is automatically
concurrent.

But I think you're conflating concurrency and parallelism.

Joost.

-- 
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


Re: Newbie: General question about concurrency in Clojure

2011-03-09 Thread Rasmus Svensson
The answer would be a mix of A and B, mostly because there seems to be
an assumption that you have to consider concurrency everywhere in
order to be able to have it at some point later. This is not the case.

You do tend to be very explicit about concurrency and only use the
concurrency primitives (refs, atoms, agents and vars) at a few
selected spots, but most of the time you don't have to think about
concurrency at all, since even the smallest parts of the system is
written in a way that allows for concurrency (by using pure functions
and not using the concurrency primitives).

Clojure is a functional programming language, which among other things
means that computation is in general carried out using referentially
transparent (pure) functions. A pure function always return the same
value for the same input and is free from side-effects. Pure functions
are always thread safe and will never be any problem to concurrency.

In a language like Java, mutation of variables and objects is very
often used for performing computations. But this intervenes
calculations that has nothing to do with each other, since a mutating
step in computation A can affect computation B if they operate on the
same objects. The result is that in Java, you have to think about
concurrency when you perform computations, unlike in Clojure.

(Here, I use the word "compute" to mean something like "produce new
data of interest".)

You tend to write the largest part of a Clojure application as
compositions of pure functions. You only have to introduce reference
primitives when you have a long-running process whose state changes
and evolves over time (for instance a game or a server, or anything
that communicates with the outside world and changes thereafter).
Clojure acknowledges the need for things to be able to change, but
keeps that separate from computation. Most library code I have written
hasn't used the concurrency primitives at all. The state changing part
of an application often resides at a higher level.

// raek

-- 
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


Re: Newbie: General question about concurrency in Clojure

2011-03-09 Thread Nick Wiedenbrueck
Thanks for your answers. Guess, I just got a little bit lost after
digging deeper into the whole thing. Just didn't see anymore that the
core problem is mutability. But it's much clearer again now.

-- 
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