Think of million of actors that are dynamically created/destroyed. Then locking and shared state becomes an important issue especially if there is randomness (graph processing , simulations).
In static problems though, dead locking and shared state is very rare and can be easily avoided through good design. 2013/4/8 Apostolis Xekoukoulotakis <[email protected]> > Here are 2 articles that I find interesting: > > http://james-iry.blogspot.gr/2009/04/erlang-style-actors-are-all-about.html > > http://james-iry.blogspot.gr/2009/04/erlang-style-actors-are-all-about_16.html > > > 2013/4/8 Eric Hill <[email protected]> > >> Agreed. The term deadlock usually indicates two bits of code contending >> for the same resource. In a message-oriented system, the message becomes >> the resource, and since one bit of code always hands the resource off to >> another bit of code, that type of deadlock cannot happen. >> >> >> On Mon, Apr 8, 2013 at 12:22 PM, A. Mark <[email protected]> wrote: >> >>> Yes that could happen, I would say that would not be considered a >>> deadlock in a classic sense. That's more like a protocol design flaw, >>> you're blocked on a message. >>> >>> >>> On Mon, Apr 8, 2013 at 10:16 AM, Timothee Besset <[email protected]>wrote: >>> >>>> I've also had deadlock cases where two threads would use several zmq >>>> sockets to communicate with each other (for instance with both a REP/REQ >>>> and a PAIR) >>>> >>>> It's easy in those cases to have deadlocks, unless you use a poll to >>>> wait on all of them at the same time. >>>> >>>> TTimo >>>> >>>> >>>> On Mon, Apr 8, 2013 at 12:04 PM, Garrett Smith <[email protected]> wrote: >>>> >>>>> On Mon, Apr 8, 2013 at 11:52 AM, A. Mark <[email protected]> wrote: >>>>> > Yes I agree, I've not had a single deadlock in a classic sense since >>>>> using >>>>> > message queues. But this statement is like saying I've hand not a >>>>> car >>>>> > accident since I've been riding a bike. You can still lock up your >>>>> code but >>>>> > it will not be a classic deadlock. I guess you could incorrectly code >>>>> > something with message queues and have it lock up occasionally. >>>>> >>>>> The one area I keep an eye on in shared-nothing single threaded >>>>> applications is accidentally waiting on one's self -- this is easy to >>>>> do, but also easy to detect and fix! >>>>> >>>>> Garrett >>>>> _______________________________________________ >>>>> zeromq-dev mailing list >>>>> [email protected] >>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> zeromq-dev mailing list >>>> [email protected] >>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>>> >>>> >>> >>> _______________________________________________ >>> zeromq-dev mailing list >>> [email protected] >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> >>> >> >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> >> > > > -- > > > Sincerely yours, > > Apostolis Xekoukoulotakis > > -- Sincerely yours, Apostolis Xekoukoulotakis
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
