
Comparing concurrent frameworks - puredanger
http://tech.puredanger.com/2011/01/14/comparing-concurrent-frameworks/
======
EGreg
Where would you fit Node.js here? I think it's a purely evented model. There's
one process and it's just done via events. Although I/O is handled largely by
queues/buffers and thread pools.

Evented pretty much gets rid of the need for locking and critical sections. At
the cost of eking out a bit more efficiency vs the actor model, and the danger
of getting stuck in a slow/infinite loop of code.

~~~
CountHackulus
_Evented pretty much gets rid of the need for locking and critical sections._

How so? If I write two events that access the same data structure and both
events fire at the same time (totally possible in a concurrent world), I still
seem some sort of locking on that data to guarantee consistency.

You may not need to write the locks explicitly, but they'll be there at least
implicitly. Personally, I'd rather control my locks (allowing coarser grain
access) than letting the compiler try and handle it. Exception safety will
mean that they'll either version the function, use a transaction, or not be
able to coalesce accesses.

~~~
samstokes
I think he meant:

 _Single-threaded entirely gets rid of the need for locking and critical
sections (so long as you don't need exclusive access to a resource for longer
than a single callback), and evented lets you recover some of the concurrency
you lost by sticking to a single thread (if you're IO-bound and you code
carefully)._

In a single-threaded event framework, even if two external events fire
simultaneously, their callbacks will be serialised because there's only one
thread to run them in, so it's as if they fired at slightly different times.
There'll be some latency processing the "second" event of course, but not too
much so long as the callback of the "first" event doesn't take long (hence the
"code carefully" part).

------
uriel
No mention of CSP? _sigh_

~~~
stopmi
Can't csp be implemented by actor-model semantics? Or are there differences
beyond the sync/async communication?

edit: not defending the article, just curious

~~~
uriel
I guess almost everything can be implemented by something else that is general
enough, the question is how convenient and practical it is.

A core concept in CSP for is channels, and I think you can mostly build that
on top of an actor-model, but I don't think that is the way I would do it.

In Go and similar languages for example it is usual to pass channels around,
and even send channels over channels, I'm not sure how one would translate
that into an actor-model, but I doubt the result would be as clear.

This is not a criticism of the actor-model, just trying to say that they
involve different ways of thinking about concurrency and trying to apply one
to the other probably will end up with a mess.

~~~
puredanger
If you send references to actors inside messages between actors, then I think
you're pretty close to the same idea. The main constraint that actors add is
that an actor has one incoming mailbox. In CSP you have more flexibility to
have multiple input channels or other arrangements. I have no idea whether
that really gives you a more interesting level of power or not.

Channels are good stuff.

