[Oorexx-devel] deadlock... why ?
Hi Still learning about concurrency in ooRexx... Why do I have a deadlock in the green line if I remove the yellow line ? Before the green line, I do guard off. So the yellow line should not have an impact on the green line... It seems that the lock is reacquired by guard on, even if the condition is not true... -- c1 = .c~new call syssleep 1 c1~m2 -- wake-up m1 say done ::class C ::method init expose s s = 0 reply guard off -- yellow line self~m1 ::method m1 expose s guard on s = 1 guard off say before guard -- here, no lock guard on when s 1 -- but here, seems locked while waiting... green line say after guard ::method m2 expose s s = 2 -- Jean-Louis -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] deadlock... why ?
Guard conditions nest. So the guard off in the m1 method does not completely remove the locking from that thread. It only removes the guarded condition caused by entry to that method, so the object is still locked by that thread. Rick On Mon, Mar 14, 2011 at 3:24 PM, Jean-Louis Faucher jfaucher...@gmail.com wrote: Hi Still learning about concurrency in ooRexx... Why do I have a deadlock in the green line if I remove the yellow line ? Before the green line, I do guard off. So the yellow line should not have an impact on the green line... It seems that the lock is reacquired by guard on, even if the condition is not true... -- c1 = .c~new call syssleep 1 c1~m2 -- wake-up m1 say done ::class C ::method init expose s s = 0 reply guard off -- yellow line self~m1 ::method m1 expose s guard on s = 1 guard off say before guard -- here, no lock guard on when s 1 -- but here, seems locked while waiting... green line say after guard ::method m2 expose s s = 2 -- Jean-Louis -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] deadlock... why ?
2011/3/14 Rick McGuire object.r...@gmail.com Guard conditions nest. So the guard off in the m1 method does not completely remove the locking from that thread. It only removes the guarded condition caused by entry to that method, so the object is still locked by that thread. ah ! ok... I learned something, today :-) thanks. Just out of curiosity : when you designed the concurrency model of ooRexx, was it derived from something already existing ? I could see some analogies with Smalltalk for some features of ooRexx, but the management of locks per variable's pool seems quite unique to ooRexx... Jean-Louis -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] deadlock... why ?
On Mon, Mar 14, 2011 at 5:50 PM, Jean-Louis Faucher jfaucher...@gmail.com wrote: 2011/3/14 Rick McGuire object.r...@gmail.com Guard conditions nest. So the guard off in the m1 method does not completely remove the locking from that thread. It only removes the guarded condition caused by entry to that method, so the object is still locked by that thread. ah ! ok... I learned something, today :-) thanks. Just out of curiosity : when you designed the concurrency model of ooRexx, was it derived from something already existing ? I could see some analogies with Smalltalk for some features of ooRexx, but the management of locks per variable's pool seems quite unique to ooRexx... The concurrency model was originally designed by Simon Nash, who definitely used Smalltalk as a model for a lot of features. The locking mechanism was an outgrowth of the class scope of the variable pools. The variable pool-based locking isolated locking in the subclasses from the locking mechanisms of the superclass. Rick Jean-Louis -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
