4 ms·

I like ZeroMQ but this slideshare doesn't deliver any substance at all. For an overview, skip it and check out the white paper (if you can call it that) cowritt

by po 16y ago

I like ZeroMQ but this slideshare doesn't deliver any substance at all. For an overview, skip it and check out the white paper (if you can call it that) cowritten by the same guy (Pieter Hintjens) instead: http://www.zeromq.org/whitepapers:multithreading-magic http://www.zeromq.org/whitepapers:multithreading-magic

thijsterlouw 16y ago
These slides were part of a "lightning talk" on ZeroMQ (video here: http://streaming.fosdem.org:8000/ferrer/0mq.ogv http://streaming.fosdem.org:8000/ferrer/0mq.ogv ). So I think Pieter just wanted to make the audience curious and not dive into the details. I do agree that it might be better to use more slides for patterns and use cases and fewer generic/actor-slides. Also the argument that it's not taught in university was a bit weak.
- phintjens 16y ago
  There's a copy of the video here: http://www.youtube.com/watch?v=CCBYzKfmQ4U http://www.youtube.com/watch?v=CCBYzKfmQ4U The FOSDEM streaming server seems to be timing out right now.
nikster 16y ago
Dunno, made perfect sense to me. It's just that many (most?) programmers, in my own experience, don't fully appreciate the insanity that is traditional "shared data" concurrency. What I see is that they program something buggy, but where the bugs are rare enough to make the program work most times.
- jshen 16y ago
  For many types of problems, shared state concurrency is not the nightmare it's often made out to be. For example, if your problem can fit into the consumer producer model then it's really easy to make that work on the jvm today.
tbrownaw 16y ago
The most widely used languages, C and C++, do not offer any support for concurrency. Programmers roll their own by using threading APIs. Languages that do support concurrency, such as Java, Python, .NET, and Ruby, do it in a brute-force manner. Depending on the implementation - there are over a dozen Ruby interpreters, for example - they may offer "green threading" or true multithreading. Neither approach scales, due to reliance on locks. It is left to exotic languages like Erlang to do it right. You know how I wrote my first concurrent programs? Create threads with pthread_create(3), and pass ownership of objects by sending pointers over connections created with pipe(3). Which sounds an awful lot like this cure-all actor model (which I hadn't heard of yet) that requires languages almost nobody's ever heard of. Of all the approaches taken to multithreading, only one is known to work properly. That means, it scales to any number of cores, ... clone(2) and socket(7) ... avoids all locks,... Your threads/actors still block waiting for messages. I've seen an example of someone using this to write a mutex in Erlang. ... costs little more than conventional single-threaded programming,... Probably depends how much you have to twist your code to fit this functional+actor model. ... is easy to learn,... If you discount having to learn a whole new language and turn your code inside-out. ... and does not crash in strange ways. Instead of crashing, it hangs because you accidentally wrote a mutex.
- toddh 16y ago
  I've built quite a few actor systems in C++ for real-time platforms. You use a threading library like pthreads, which works fine in C++, use thread safe libraries, create an Actor object with a queue that encapsulates a thread, and then have your async messaging system route and drop messages in the right actor queue. As long as application writers can manage their impulses to share state between the threads it works excellently. The only problem is usually the shared state inherent in the memory allocator, so some sort of thread based memory allocation scheme works best. You also get to choose your response latency via priority, which is something you don't get with Erlang.
  - defen 16y ago
    Keep in mind that the original point of erlang was "reliable software", not "high performance" (quotes because those are fuzzy terms) - there are many classes of errors that simply cannot happen in erlang that happen all the time in real-world C++ programming. You also get distributed computation for free via a well-tested VM.

by po 16y ago

thijsterlouw 16y ago

These slides were part of a "lightning talk" on ZeroMQ (video here: http://streaming.fosdem.org:8000/ferrer/0mq.ogv http://streaming.fosdem.org:8000/ferrer/0mq.ogv ). So I think Pieter just wanted to make the audience curious and not dive into the details. I do agree that it might be better to use more slides for patterns and use cases and fewer generic/actor-slides. Also the argument that it's not taught in university was a bit weak.

phintjens 16y ago
There's a copy of the video here: http://www.youtube.com/watch?v=CCBYzKfmQ4U http://www.youtube.com/watch?v=CCBYzKfmQ4U The FOSDEM streaming server seems to be timing out right now.

nikster 16y ago

Dunno, made perfect sense to me. It's just that many (most?) programmers, in my own experience, don't fully appreciate the insanity that is traditional "shared data" concurrency. What I see is that they program something buggy, but where the bugs are rare enough to make the program work most times.

jshen 16y ago
For many types of problems, shared state concurrency is not the nightmare it's often made out to be. For example, if your problem can fit into the consumer producer model then it's really easy to make that work on the jvm today.

tbrownaw 16y ago

The most widely used languages, C and C++, do not offer any support for concurrency. Programmers roll their own by using threading APIs. Languages that do support concurrency, such as Java, Python, .NET, and Ruby, do it in a brute-force manner. Depending on the implementation - there are over a dozen Ruby interpreters, for example - they may offer "green threading" or true multithreading. Neither approach scales, due to reliance on locks. It is left to exotic languages like Erlang to do it right. You know how I wrote my first concurrent programs? Create threads with pthread_create(3), and pass ownership of objects by sending pointers over connections created with pipe(3). Which sounds an awful lot like this cure-all actor model (which I hadn't heard of yet) that requires languages almost nobody's ever heard of. Of all the approaches taken to multithreading, only one is known to work properly. That means, it scales to any number of cores, ... clone(2) and socket(7) ... avoids all locks,... Your threads/actors still block waiting for messages. I've seen an example of someone using this to write a mutex in Erlang. ... costs little more than conventional single-threaded programming,... Probably depends how much you have to twist your code to fit this functional+actor model. ... is easy to learn,... If you discount having to learn a whole new language and turn your code inside-out. ... and does not crash in strange ways. Instead of crashing, it hangs because you accidentally wrote a mutex.

toddh 16y ago
I've built quite a few actor systems in C++ for real-time platforms. You use a threading library like pthreads, which works fine in C++, use thread safe libraries, create an Actor object with a queue that encapsulates a thread, and then have your async messaging system route and drop messages in the right actor queue. As long as application writers can manage their impulses to share state between the threads it works excellently. The only problem is usually the shared state inherent in the memory allocator, so some sort of thread based memory allocation scheme works best. You also get to choose your response latency via priority, which is something you don't get with Erlang.
- defen 16y ago
  Keep in mind that the original point of erlang was "reliable software", not "high performance" (quotes because those are fuzzy terms) - there are many classes of errors that simply cannot happen in erlang that happen all the time in real-world C++ programming. You also get distributed computation for free via a well-tested VM.