SXE Modification: Final Report

1
SXE ModificationFinal Report

• Sowmya Manjanatha
• Zhinan Jenny Han
• Jorge Londoño

2
Overview

• Goals
• Design
• Implementation issues
• Testing
• Conclusions

3
Goals

• Enable concurrent execution of nodes of STEP
  programs
• Without affecting the semantics of the STEP
  program itself.
• Safe from race conditions
• According to some scheduling policies
• Extensibility of implementation to other types of
  schedulers

4
Design

• Various schedulers
• Simple Scheduler
• Hierarchical, priority based
• Weighted Round Robin
• Selection of scheduler and its parameters based
  on a configuration file, handled by a Factory
  class
• Trace and monitoring

5
Simple Scheduler
Waiting
Not Enabled
Dependencies resolved
Thread Pool
STEP Scheduler
Ready
Enabled
6
Hierarchical
7
Weighted Round Robin
8
Runtime configuration

• Let the user specify scheduler that best matches
  its own needs.
• General Idea
• Configuration stored in scheduler.properties
• Factory class instances the right scheduler and
  passes the parameters given in the configuration
  file.
• Factory also enforces Singleton pattern on
  scheduler.

9
Trace and monitoring

• Facilitate tracing of program execution.
• Tracing can be enabled/disabled from
  configuration file
• Trace level can be adjusted
• Very helpful to detect and debug the program
• Performance Monitoring

10
Implementation Concurrency
11
Integration with SXE

• Three connection points
• Initialization Initialize scheduler subsystem
  using factory and configuration file.
• Program reception Schedule the roots of the
  graph
• Triggers Need special treatment, as triggers
  should schedule for execution the predicate or
  the body according to the triggers state.

12
Testing

• Configuration parameters and initialization.
• Boundary conditions.
• Used standard tools JUnit

• Correct operation of schedulers
• Queueing/dequeuing
• Flowtypes to assign class/priority/weight.
• Order of evaluation
• Scheduling of waiting nodes.

• Unit testing

• Functional testing

• Operation within SXE
• Used manual analysis of traces.

• Integration testing

• Tried some methods based on traces to automate
  regression tests.
• Very difficult due to the non-deterministic
  nature of the program execution.

• Regression testing

13
Conclusions

• Design provided a clear path for implementation.
  Coding required minimal effort.

14
Conclusions

• Unit testing difficult in complex projects such
  as SNBENCH because of dependencies. Even with
  these limitations, helped reveal many special
  cases not considered initially in the
  design/implementation.
• Number of cases to consider, even for a small
  project may be too large. Writing unit test may
  be a major task.

15
Conclusions

• Integration testing Difficult because need to
  have whole system in operation. Traces are very
  large. Manually checking a trace is very error
  prone and requires detailed knowledge of the
  system under test.

16
Demo
Class 0
Class 1
17
Thanks!