UCoM Software Architecture

1
UCoM Software Architecture

• http//ucom

2
UCoM Programming Model

• The Problem
• Multi-threaded code is difficult to write and
  debug. Our goal is to reduce subtle concurrency
  bugs and race conditions
• Our Approach
• Program written in terms of tasks that are not
  pre-emptively scheduled, i.e., cooperative
  multi-tasking
• No mutual exclusion work by programmer
• Only one task active at any time

3
What are Tasks in UCoM

• Sequence of operations possibly containing I/O
  operations (e.g., network receives)
• Whole address space is locked for the task
  until it relinquishes control Piecewise Serial
• Lock released automatically when task performs
  I/O
• Programmer must validate state after
  reacquiring lock similar to high-performance
  servers
• Like event-driven programming but without
  inconvenience of using continuation-passing style
  in C/C/C.

4
Support for UCoM Tasks

• Threads needed to achieve task abstraction
• Scheduler thread for controlling execution
• One or more threads per type of I/O network,
  disk, UI, brick
• Pool of worker threads for programmer tasks
  Win32 fibers would be better but not available in
  WinCE
• When I/O request (e.g., file read) occurs in a
  task
• Event posted on relevant I/O thread task
  scheduled out
• I/O completes result posted on scheduler thread
• Worker thread resumed ultimately with result