Comparing concurrent frameworks
tech.puredanger.com
Comparing concurrent frameworks
1–10 of 11 posts
Re: Comparing concurrent frameworks
#2Where 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.
Re: Comparing concurrent frameworks
#3[deleted]
Re: Comparing concurrent frameworks
#4Where 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.
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.
Re: Comparing concurrent frameworks
#5No mention of CSP? sigh
Re: Comparing concurrent frameworks
#6Where 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.
Node.js doesn't fit in there because it's not concurrent. There's some threaded IO under the hood, but there's only one thread executing javascript.
Re: Comparing concurrent frameworks
#7No mention of CSP? sigh
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
Re: Comparing concurrent frameworks
#8No mention of CSP? sigh
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
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.
Re: Comparing concurrent frameworks
#9Where 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.
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 l…
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).
Re: Comparing concurrent frameworks
#10No mention of CSP? sigh
I'm the OP. I almost mentioned CSP in the article but decided I was pushing the limits of the post already and many of the ideas were already covered in actors or data flow. At the level I was talking, I have a hard time seeing the differences between actors and CSP, but I know a lot less about CSP.