Goswin-- Thank goodness. I'm not alone.
I did a little research, now better than never: http://james-iry.blogspot.com/2009/04/erlang-style-actors-are-all-about_16.html (Actor patterns are all about locking) http://people.inf.ethz.ch/chmaria/Pubs/TFP-2011.pdf (in this second one, they state: "... However, Erlang does not avoid all problems associated with concurrent execution. In particular, it provides for interactions and communication patterns between processes that may be stuck in their execution until some conditions are met, hence allowing certain kinds of deadlocks in programs. In addition, as Erlang's primary application area is in large-scale, reactive control systems that create an unbounded number of processes, such as server applications, these pro- cess interactions become complex and extremely hard to predict. Not only that, but also deadlocks may remain unexposed during testing and when revealed, it is quite distressing to reproduce them, let alone find their cause.") http://lambda-the-ultimate.org/node/4908#comment-79110 (How JActor helps avoid Actor deadlocks...) And so on. Anyone with words of wisdom? Is there no easy way out of this mess? Pieter, am I missing the forest for the trees here? murf On Fri, Aug 29, 2014 at 5:02 AM, Goswin von Brederlow <goswin-...@web.de> wrote: > On Thu, Aug 28, 2014 at 08:58:49AM -0600, Steve Murphy 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 > > ??? > > You can't solve the problem. As soon as you have a "wait for > completion/reply" operation it is always possible to have a deadlock. > Any time something can block you can have a deadlock. You can analyze > the code to see if deadlocks are possible but that gets complex > quickly. > > You can avoid the situation by not blocking, which means you can never > change 2 objects atomically. That limits what you can do. > > You can give objects an order (A < B < C) and only allow locking of > objects in order. So a thread that holds a lock on B can never ever > lock object A. That makes it impossible to deadlock. But prooving that > your source will never violate the order is hard and at runtime all > you can do is give an error, often an unrecoverable one (since the > case should never happen in the first place nobody writes code to > recover from it). > > You can also hide groups of objects behind a single gatekeeper that > never deadlocks and can't be locked. The problem with deadlocks is > that a thread can block waiting while blocking something else (or the > same thing). If all access to a group of objects goes through a > gatekeeper and the gatekeeper itself can't deadlock then the whole > can't deadlock. The gatekeeper acts as a lock for the whole group. The > drawback is that it acts as a lock for the whole group. You loose > parallelity unless the gatekeeper is clever enough to run non > conflicting operations in parallel. > > So in reality you have to balance between locking individual objects > and risking deadlocks versus locking groups and being slow. > > MfG > Goswin > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > -- 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
