[zeromq-dev] Is it possible to get deadlocks in ZeroMQ applications?
Apostolis Xekoukoulotakis
xekoukou at gmail.com
Mon Apr 8 21:04:59 CEST 2013
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 <xekoukou at gmail.com>
> 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 <eric at ijack.net>
>
>> 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 <gougolith at gmail.com> 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 <ttimo at ttimo.net>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 <g at rre.tt> wrote:
>>>>
>>>>> On Mon, Apr 8, 2013 at 11:52 AM, A. Mark <gougolith at gmail.com> 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
>>>>> zeromq-dev at lists.zeromq.org
>>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> zeromq-dev mailing list
>>>> zeromq-dev at lists.zeromq.org
>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> zeromq-dev mailing list
>>> zeromq-dev at lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>>>
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
>
>
> --
>
>
> Sincerely yours,
>
> Apostolis Xekoukoulotakis
>
>
--
Sincerely yours,
Apostolis Xekoukoulotakis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130408/771f7fa5/attachment.htm>
More information about the zeromq-dev
mailing list