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

Already on GitHub? Sign in to your account

Bug in scheduler #28

Open
krestenkrab opened this Issue Jun 2, 2010 · 2 comments

Comments

Projects
None yet
2 participants
Owner

krestenkrab commented Jun 2, 2010

java.util.NoSuchElementException
at java.util.LinkedList.remove(LinkedList.java:788)
at java.util.LinkedList.removeFirst(LinkedList.java:134)
at java.util.LinkedList.poll(LinkedList.java:470)
at kilim.Scheduler.schedule(Scheduler.java:67)
at kilim.Task.resume(Task.java:203)
at kilim.Task._runExecute(Task.java:448)
at kilim.WorkerThread.run(WorkerThread.java:47)
[java] exiting <0.0.4> with: java.util.NoSuchElementException
<0.0.4>4(running=true,pr=null)::erlang:apply/2
at java.util.LinkedList.remove(LinkedList.java:788)
at java.util.LinkedList.removeFirst(LinkedList.java:134)
at java.util.LinkedList.poll(LinkedList.java:470)
at kilim.Scheduler.schedule(Scheduler.java:67)
at kilim.Task.resume(Task.java:203)
at kilim.Task.messageAvailable(Task.java:178)
at kilim.Mailbox.put(Mailbox.java:318)
at kilim.Mailbox.put(Mailbox.java:411)
at erjang.driver.EDriverTask.close(EDriverTask.java:574)
at erjang.EInternalPort.close(EInternalPort.java:181)
at erjang.m.erlang.ErlPort.port_close(ErlPort.java:354)
at erjang.m.prim_file.prim_file.drv_close__1(prim_file.S:219)
at erjang.m.prim_file.prim_file$FN_drv_close__1.go(Unknown Source)
at erjang.m.prim_file.prim_file.close__1$call(prim_file.S)
at erjang.m.prim_file.prim_file.read_file__1(prim_file.S:96)
at erjang.m.prim_file.prim_file$FN_read_file__1.invoke(Unknown Source)

Contributor

eriksoe commented Nov 21, 2010

kilim.Scheduler's constructor is not written in a way conformant with the Java memory model (i.e., in a way guaranteed not to give problems).
This includes, but is not limited to, problems when Scheduler is derived from.
The problem is that the constructor "leaks" self - it makes 'this' be available (to other threads) before the Scheduler object has been completely constructed.
(Note that this problem would go away if the constructor refrained from starting the worker threads; creating the Thread objects in itself is not a problem.)

Contributor

eriksoe commented Nov 21, 2010

Looking at the Scheduler source code, I think the following two changes should be enough to make 'waitingThreads' be handled in a guaranteed thread-safe manner are:

  • Prevent the constructor from starting its worker threads
  • Make waitingThreads be final.

Possibly, it would be enough to

  • Make the constructor work in two passes: First populate 'waitingThreads', then start all the worker threads.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment