You may enjoy the CZMQ zactor model, which is somewhat inspired by Erlang's view of things.
On Thu, Aug 28, 2014 at 4:58 PM, Steve Murphy <m...@parsetree.com> wrote: > Pieter-- > > Last year, I read the book, Programming Erlang, by Joe Armstrong, and I was > fascinated by the ideology behind the general thread-per-object approach, > where > each "object" is managed by its own thread, via message passing. > > Erlang has a really "involved" message passing scheme, involving pattern > matching, a "mailbox", recieve timer, a "save queue". Needless to say, all > this makes a very powerful way of prioritizing messages, so a busy object > manager can pull high-priority requests from the mailbox and act on them > immediately, saving lower priority requests for later. > > I see in a paper at http://zeromq.org/blog:multithreading-magic, the same > sort of admiration for Erlang's methodology. > > But... > > I'm not seeing the cure-all, end-all, solution to concurrency problems, and > it bothers me, because I'm probably missing something fundamental, something > I should have picked up on, but didn't. > > Erlang allows other processes/threads to drop requests in an object's > mailbox, but > it also has a mechanism for waiting until the action is complete, as the > "object" > can send a response. > > It's this response wait that is the killer. Now, I've done a lot of work > on/with Asterisk, > and it is heavily mulithreaded, in the old-school way, and has a ton of > critical > sections, and locks, and mutiple locks for a single action. They have > evolved > some fairly involved strategies to avoid deadlocks, including putting a > timer > on the lock, and if it times out, giving up the lock they already have, and > starting > over, allowing the contending party to obtain the lock they need, finish > their > "thing", which allows you to continue and obtain the lock you need to do > your > "thing". And on and on it goes. > > Now, I didn't go and look up the particulars about "N-party dance", etc., > but > the classic resource deadlock situations still seem > in play when you have to wait for completion. A asks B to > complete a task, and waits for him to respond. In order to get that done, B > requests > A for something, and waits forever for A to finish. And so on. Perhaps C or > even D > are also involved. > I keep thinking that such basic situations > aren't solved by > switching to the Erlang methods. There must be some architectural, perhaps > hierarchical organizing, > some sort of general design practice, that can > overcome these kinds of problems, I'm just blind to it at the moment. > > Situations like 'atomic' changes on two or more objects at once, etc. and I > don't > see in the fog, how Erlang solves these problems in general. Can someone > point me to some literature that might make things clear? > > murf > > -- > > Steve Murphy > ParseTree Corporation > 57 Lane 17 > Cody, WY 82414 > ✉ murf at parsetree dot com > ☎ 307-899-5535 > > > > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
