tag:blogger.com,1999:blog-178174920347765771.post6116630211443016162..comments2023-10-30T09:20:21.742-07:00Comments on One Div Zero: Erlang Style Actors Are All About LockingJames Iryhttp://www.blogger.com/profile/02835376424060382389noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-178174920347765771.post-59558224161818835762009-04-29T10:18:00.000-07:002009-04-29T10:18:00.000-07:00Greg, you're right! I managed to paste a broken v...Greg, you're right! I managed to paste a broken version into the post. I'll fix it.James Iryhttps://www.blogger.com/profile/02835376424060382389noreply@blogger.comtag:blogger.com,1999:blog-178174920347765771.post-45570715977342721692009-04-29T09:21:00.000-07:002009-04-29T09:21:00.000-07:00I'm no expert but it looks like if your mutex is a...I'm no expert but it looks like if your mutex is already locked it won't send ok back to the locking process to wake it up to leave the lock function. So recursively locking your mutex is broken and guaranteed to deadlock.Greg Rogersnoreply@blogger.comtag:blogger.com,1999:blog-178174920347765771.post-31189184174853872872009-04-22T20:17:00.000-07:002009-04-22T20:17:00.000-07:00I'm not an Erlang expert, at all, but while it's t...I'm not an Erlang expert, at all, but while it's true that deadlock can occur with a poorly designed communications protocol, Erlang/OTP gives programmers better tools to avoid this. <br /><br />Of course, the first thing is to avoid bad designs :)<br /><br />But since everyone can write buggy code, a receive with a timeout will probably solve your situation. <br />Also, using OTP's supervision Fernando Iparhttp://fernandoipar.comnoreply@blogger.comtag:blogger.com,1999:blog-178174920347765771.post-1509378941071084632009-04-17T13:19:00.000-07:002009-04-17T13:19:00.000-07:00Having two gen_servers call each other cyclically ...Having two gen_servers call each other cyclically was one of the first deadlocks I ran into implementing Reia, a hybrid object/actor language for the Erlang VM. Reia uses gen_server as the basis of its objects, and as it guises gen_server calls in traditional obj.method(arg1, arg2...) style syntax it's easy to accidentally have two objects call each other cyclically.<br /><br />I believe we haveTonyhttps://www.blogger.com/profile/05698660503129206682noreply@blogger.comtag:blogger.com,1999:blog-178174920347765771.post-47261139366851975282009-04-17T13:16:00.000-07:002009-04-17T13:16:00.000-07:00Badly designed communication protocols can deadloc...Badly designed communication protocols can deadlock - yes, isn't this rather obvious? <br /><br />Who is arguing that this is not the case? Please share a few links. I am curious.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-178174920347765771.post-14643626407199100522009-04-17T11:59:00.000-07:002009-04-17T11:59:00.000-07:00I agree. Deadlock and race conditions can still ha...I agree. Deadlock and race conditions can still happen. One of the simple ways to create a deadlock is to have two generic servers call each other. If you haven't selected Timeout = infinity, at least you won't have to wait forever...<br /><br />I fact, some Erlang programmers have tried to avoid deadlock by changing (synchronous) calls to (asynchronous) casts. It's very important to understand Ulf Wigerhttps://www.blogger.com/profile/14415790008413375634noreply@blogger.comtag:blogger.com,1999:blog-178174920347765771.post-34567006288838626802009-04-17T09:47:00.000-07:002009-04-17T09:47:00.000-07:00echo "I think you're using the words wron...echo "I think you're using the words wrong" > /dev/nullMihainoreply@blogger.com