Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vtime and termination do not behave as expected and cause an interpreter deadlock #190

Open
arthurp opened this issue Feb 17, 2017 · 1 comment

Comments

@arthurp
Copy link
Member

arthurp commented Feb 17, 2017

Program

x <Some(x)<  Vclock(IntegerTimeOrder) >> (
      (Vawait(0) >> Some(f()) ; None() ) |
      Vawait(1) >> Some(g())
    ) 

Expected behavior

This program should execute f() and if it becomes quiescent, but not halted, the program will execute g(). If f() halts then None() will be published immediately without going quiescent. If either f() or g() publishes the whole thing should be killed. This means that if f() publishes without becoming quiescent (for instance f() = signal), then g() should never run.

Actual behavior

g() runs after f() publishes. And just to really rub it in the interpreter deadlocks.

The deadlock is a lock ordering problem. VirtualClock takes its own lock and then calls checkAlive on a handle which can take the lock of a group up the tree. Group kills take the Group lock and then call unsetQuiescent which takes the VirtualClock lock.

This issue appears to exist in both the released version and master.

Test program

-- Run g if f becomes idle/quiescent but not halted. Kill the whole mess when either half publishes.
def ifIdle[A](f :: lambda() :: A, g :: lambda() :: A) :: A = 
  x <Some(x)<  Vclock(IntegerTimeOrder) >> (
      (Vawait(0) >> Some(f()) ; None() ) |
      Vawait(1) >> Some(g())
    ) 
  

val c = Channel()

def test() = 
  ifIdle(lambda() = "Publish from left", lambda() = Println("FAIL: publication idle")) |
  stop

def f(n) if (n :> 0) = 
  test() >x> Println(x) >> stop ; Println("============") >> f(n-1)

f(1000)
@arthurp arthurp added this to the 2.2 milestone Feb 17, 2017
@arthurp
Copy link
Member Author

arthurp commented Feb 17, 2017

In initial work on trying to solve this (when I thought it might be simple) I made the following changes which might be useful to others: Patch.

arthurp added a commit that referenced this issue Feb 17, 2017
This discovered a bug in the interpreter: issue #190.
@arthurp arthurp changed the title Vtime and termination do not behave as expected and cause an interpreter deadline Vtime and termination do not behave as expected and cause an interpreter deadlock Feb 18, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant