1. Concurrent Graph Exploration with Multiple Robots
Hui Wang

2. Outline Review of the basic problem Purpose and plan of this exercise
Current work -- experiencing JPF
Summary
2/22/2019

3. Outline Review of the basic problem Purpose and plan of this exercise
Current work -- experiencing JPF
Summary
2/22/2019

4. Review of the basic problem
Exploring graph-like world with multiple robots
Common starting place
Exploring in parallel
Gut: Use marker (bread crumbs) to disambiguate places
Alternating phases of
common map := initial starting place
while common map has unexplored part
Partition the common map (Task split)
Explore in parallel
Meet at rendezvous place (common) after a certain time steps
Merge the partial maps
Merged map shared by all robots, becoming new common map
end while
independent exploration
coordinated merging of partial representations
2/22/2019

5. Multiple robot exploration example
2/22/2019

6. Concurrency-related practice
Basic design
Each robot represented by a thread
Share underlying data structure (the graph)
Communication by shared memory
Non-rendezvous place: lock current place for accessing and updating
place := current place
synchronized (place) {
accessing & updating the place … }
Rendezvous place: sleep and wake up
if nobody here //earlier one
place.wait();
else // later one
place.notifyAll(); …
2/22/2019

7. Exploiting event ordering ---- basic algorithm + vector clock
Upon on arrival, retrieve other’s traverse info
The other robot may have traversed some to-be-visited nodes
Which happened after my latest drop
Seen / not seen my marker -- helpful
Another robot’s traversal history
- I have visited A C F H
- at logical time
0,2
2,3
3,4
3,5
I am in searching stage
I dropped (at unknown
place) at time (3,2)
I still need to search node
[B C D E F G H]
- seen your marker?  X X X
The marker must not at F & H !!!
I will need to search node
[B C D E F G H]
2/22/2019

8. Outline Review of the basic problem Purpose and plan of this exercise
Current work -- experiencing JPF
Summary
2/22/2019

9. Purpose and plan of this exercise
Experiencing Java PathFinder
Basic practice on JPF
Try listener, modeling class ……
Capturing different paths of exploration
Investigate how different paths affect performance
2/22/2019

10. Outline Review of the basic problem Purpose and plan of this exercise
Current work -- experiencing JPF
Summary
2/22/2019

11. Current work -- experiencing JPF
Beyond the default settings of JPF
Add
jpf.listener = gov.nasa.jpf.tools.precise.PreciseRaceDetector
to jpf.properties file.
Add (alternative)
search.class = gov.nasa.jpf.search.heuristic.HeuristicSearch search.heuristic.class = gov.nasa.jpf.search.heuristic.BFSHeuristic to jpf.properties file.
2/22/2019

12. Current work -- experiencing JPF
-java Main graphfile scriptfile
-jpf Main graphfile scriptfile
Problem: native code
====================================================== trace #1
transition #0 thread: 0
gov.nasa.jpf.jvm.choice.ThreadChoiceFromSet {>main} [14 insn w/o sources]
Main.java: : rd = new FileReader(args[0]);
====================================================== snapshot #1
thread
owned
call stack:
at sun.misc.VM.<clinit>(VM.java:332)
at java.nio.charset.Charset.atBugLevel(Charset.java:250)
at java.nio.charset.Charset.checkName(Charset.java:272)
at java.nio.charset.Charset.<init>(Charset.java:611)
at sun.nio.cs.US_ASCII.<init>(US_ASCII.java:27)
at sun.nio.cs.FastCharsetProvider.lookup(FastCharsetProvider.java:95)
at sun.nio.cs.FastCharsetProvider.charsetForName(FastCharsetProvider.java:119)
at java.nio.charset.Charset.lookup2(Charset.java:450)
at java.nio.charset.Charset.lookup(Charset.java:438)
at java.nio.charset.Charset.defaultCharset(Charset.java:580)
at sun.nio.cs.StreamDecoder.forInputStreamReader(StreamDecoder.java:47)
at java.io.InputStreamReader.<init>(InputStreamReader.java:57)
at java.io.FileReader.<init>(FileReader.java:41)
at Main.main(Main.java:22)
====================================================== results
error #1: gov.nasa.jpf.jvm.NoUncaughtExceptionsProperty "java.lang.UnsatisfiedLinkError: sun..."
====================================================== search finished: 11/23/07 7:02 PM
Attempted solution: coding parameters
-java Main - jpf Main
2/22/2019

13. Current work -- experiencing JPF
Input graph (coded) : 3*3 lattice
-java Main (220 steps, 2 seconds)
-jpf Main
Problem: Crashes at the beginning
/cs/fac/bin/jpf: line 59: Killed
java $JVM_FLAGS -classpath "$CP" gov.nasa.jpf.JPF +jpf.basedir="$JPF_HOME"
Possible cause : large size of critical data structure
E.g., 1000*1000 element array for Dijkstra
Attempted solution: reduce the critical data structure to small size
E.g., max 10*10 element array
2/22/2019

14. Current work -- experiencing JPF
Reduced data structure
Input graph (coded) : 3*3 lattice
Run: -java Main 200 steps, 2 seconds
Problem: crashes in the middle (quickly)
0 go from 8 ->5 step 142 local: 2 -> 0===+++++========++++========++==
java.lang.OutOfMemoryError: Java heap space at
gov.nasa.jpf.jvm.CollapsingRestorer.computeRestorableData(CollapsingRestorer.java:57)
at gov.nasa.jpf.jvm.CollapsingRestorer.computeRestorableData(CollapsingRestorer.java:1)
at gov.nasa.jpf.jvm.AbstractRestorer.getRestorableData(AbstractRestorer.java:35)
at gov.nasa.jpf.jvm.DefaultBacktracker.pushKernelState(DefaultBacktracker.java:82)
at gov.nasa.jpf.jvm.JVM.forward(JVM.java:1186)
at gov.nasa.jpf.search.Search.forward(Search.java:369)
at gov.nasa.jpf.search.DFSearch.search(DFSearch.java:86)
at gov.nasa.jpf.JPF.run(JPF.java:366)
at gov.nasa.jpf.JPF.main(JPF.java:297) Or
/cs/fac/bin/jpf: line 59: Killed java $JVM_FLAGS -classpath "$CP" gov.nasa.jpf.JPF +jpf.basedir="$JPF_HOME"
Attempted solution: reduce the input graph to tiny size
E.g., 3 node string
2/22/2019

15. Current work -- experiencing JPF
Reduced input: 3 node string
Run normal exploration (with merge etc)
Run: -java Main 55 steps
Crashes after many hours
/cs/fac/bin/jpf: line 59: Killed java $JVM_FLAGS -classpath "$CP" gov.nasa.jpf.JPF +jpf.basedir="$JPF_HOME"
Run one exploration phase only
Run: -java Main 16 steps
0 add a new node 2 local XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
/cs/fac/bin/jpf: line 59: Killed java $JVM_FLAGS -classpath "$CP“
gov.nasa.jpf.JPF +jpf.basedir="$JPF_HOME"
Limit the steps that the robots can take ?
E.g., terminate after 3 steps
2/22/2019

16. Limit the steps that robots can take
Current work -- experiencing JPF
Limit the steps that robots can take
Starting from middle
7 steps endlessly + crashes
3 steps endlessly + crashes
1 steps 5 hours
Starting from one end (one robot can actually move)
7 steps 8 hours
3 steps 3 hours
1 steps 1.3 hours
Really start only one robot?
Immediately 1 minute r2 r1
1 go from 0 ->2 step 2 local: -1 -> 0===+++++========++++========++==
/cs/fac/bin/jpf: line 59: Killed
java $JVM_FLAGS -classpath "$CP" gov.nasa.jpf.JPF +jpf.basedir="$JPF_HOME" r2 r1
========================
I am back using 1 steps --- false
====================== results
no errors detected
====================== search finished: 11/23/07 12:38 PM
2/22/2019

17. Current work -- experiencing JPF
Limit the steps that robots can take + less ‘intelligence’
Remove code for ≥ 5 steps,
No disambiguation etc
No traversal information …
Starting from middle
7 steps endlessly + crashes
3 steps endlessly + crashes 7 hours
1 steps 5 hours hours
Starting from one side (one robot can actually move)
7 steps 8 hours
3 steps 3 hours hours
1 steps 1.3 hours hour
Further simplified?
Traverse list (string) only? r2 r1 r2 r1
2/22/2019

18. Current work -- experiencing JPF
Traverse list (string) only - ‘little intelligence’ every 4 node
Earlier locks & writes, later locks & reads, identical
Earlier waits for the later, when waking up, one designated writer, one designated reader
Traverse list (string) only – almost ‘intelligent-less’
Earlier lock & write, later lock & read
Completely identical r1 r2 r1 r2
2/22/2019

19. Current work -- experiencing JPF
Traverse list (string) only - ‘little intelligence’
Wait each other every 4 nodes, one designated writer, one designated reader
≥ 50 nodes -- endlessly + crashes, after ≥ 2 hours
/cs/fac/bin/jpf: line 59: Killed java $JVM_FLAGS –classpath …
Traverse list (string) only – almost ‘intelligent-less’ and identical
2/22/2019

20. Outline Review of the basic problem Purpose and plan of this exercise
Current work -- experiencing JPF
Summary
2/22/2019

21. Summary Deal with native code Reduce state space
Reduce size of critical data structure
Reduce size of input graph
Limit the steps the robots can take
Move two robots
Move one robot
Reduce “intelligence” of the robots
Compare with model of almost no intelligence robots
Other efforts (preliminary)
BFS (killed)
Race condition (found!) r2 r1 r1 r2
2/22/2019

22. Summary Many factors determining state space Future work Input size
Number of active threads
Even codes that are not actually executed
Even for simple case, space may increases dramatically over input size
Future work
BFS
Race condition
Capture the number of paths
in space for comparison
More?
2/22/2019

23. Thank you
2/22/2019

24. Extra :Current work -- experiencing JPF
Almost “intelligent-less” robots
≥ 50 nodes -- endlessly + crashes after ≥ 2hours
/cs/fac/bin/jpf: line 59: Killed java $JVM_FLAGS –classpath
"$CP"gov.nasa.jpf.JPF +jpf.basedir="$JPF_HOME"
2/22/2019

25. extra 1 is at 32 1 @ 31 write 0 [SEVERE] JPF out of memory
====================================================== results
no errors detected
====================================================== search finished: 11/25/07 7:13 PM
2/22/2019

26. extra
40 nodes killed
0 /cs/fac/bin/jpf: line 59: Killed java $JVM_FLAGS -classpath "$CP" gov.nasa.jpf.JPF +jpf.basedir="$JPF_HOME"
2/22/2019

27. Extra: Exploiting event ordering in our problem
Objective
Does logical vector time really works?
Can we exploit it?
Each edge traversal is an event
Synchronized as much as necessary, requiring communication
Robot dumps all traversal history up on a vertex
Label of the node traversed , logic time stamp, whether other’s marker is seen
For other robot to observe
At least synchronizes logical time
Another robot’s traversal history
- I have visited A C F H
My last event time (5,3)
- at logical time
0,2
0,3
3,4
3,5
- seen others marker? X  X X
My current event time (6,5)
2/22/2019

28. Extra: Exploiting event ordering -- scenario II
Upon on arrival, retrieve other’s traverse info
The other traversed some to-be-visit node
Which happened after my latest drop
Have seen my marker
Another robot’s traverse history
- I have visited: A C F H
- at logical time:
0,2
2,3
3,4
3,5
- I am in searching stage
- I dropped at time (3,2)
I still need to search node
[B C D E F G H]
- seen your marker?:  X  X
My marker is at node F !!!
I will need to search node
[B C D E F G H]
2/22/2019

29. Thank you Extra: References Logical clocks
[1] Lamport, L Time, Clocks and the Ordering of Events in a Distributed System. Communications of the ACM 21 (7): 558–
Vector logical clocks
[2] Mattern, F. Virtual time and global states of distributed systems. In M. Cosnar, editor, Proceedings of the International Workshop on Parallel and Distributed Algorithms, pages , 1989.
[3] Fidge, C Timestamps in message-passing systems that preserve the partial ordering. In K. Raymond, editor, Proceedings of the 11th Australian Computer Science Conference (ACSC'88), pages 56-66, 1988.
Thank you
2/22/2019

30. Extra: Summary and future work
Good experience of concurrency-related knowledge
Too many directions of future work
This is simple model, may not real
Ignore possible enhancements that are not related to event ordering
2/22/2019

31. Extra: more work Marker seen and drop record Dump partial map instead
Use history as unique identification
Multiple robots, multiple markers
2/22/2019

32. Extra: work of vector clock
Initially all counts in the vector are zero
Each time a process experiences an internal event, it increments its own event count in the vector by one
Each time a process prepares to send a message, it increments its own event count in the vector by one and then sends its entire vector along with the message being sent
Each time a process receives a message, it increments its own event count in the vector by one and updates each element (count) in its vector by taking the maximum of the value in its own vector clock and the value in the vector in the received message (for every element).
2/22/2019

33. Extra slide: Two robots vs. single robot
2/22/2019