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
