FACE Project

 - Putting executable files in the POSIX file system.
 - Putting kernel, PAL, or registry in the POSIX file system.

GET_PARTITION_STATUS
// values from 653 config file, plus lock level, operating mode, start condition, all managed by 653 lib

SET_PARTITION_MODE
// Idle
   // deleteProcess

// ColdStart
   // restartProcess

// WarmStart
   // wake up initial thread
   // delete all 653 objects, Deos threads, Deos events
   // do restartentry stuff to run main
   // set flags to know start condition, operating mode
   // restart main thread

// Normal
   // start all 653 processes
   // aperiodic - make them ready now
   // periodic - calculate the next release point (window with periodic processing start)
   // calculate deadlines and if out of range raise exception for HM
   // wait on an event until warm start needs to wake us up.
   // Note this may mean there are no threads in the scheduler ready until periodic window starts

CREATE_PROCESS
  // error checks
  // createEvent to use for process synchronization and suspension
  // createThreadEx
     // process is periodic if it has a period
     // process has deadline if it has a time_capacity (Wall time, can be replenished with API)

  // create 653 object and return
  // set entry point to a library routine preamble that can run to the suspension event

SET_PRIORITY
  // find thread
  // error checks
  // waiting resource queues do not have to be reordered
  // setThreadPriority (must move to end for requested priority, so this can be a yield)

SUSPEND_SELF
// error checks
// if no timeout, return done
// mark us as suspended in 653 lib
// waitForEvent (suspensionEvent, timeout)  (Validate timeout plus how do we pass 64 bit relative (or converted to absolute) timeout?)
// when return timed out or someone resumed us
// clear suspended flag

SUSPEND
// error checks
// mark thread as suspended in 653 lib
// raiseException to the thread and have it waitForEvent (suspensionEvent, waitIndefinite)
// when return someone resumed us, clear suspended flag

Another option would be to set the priority to idle-1.

RESUME
// error checks
// clear suspended flag for thread
// if process was suspended while waiting on a resource (blackboard, event, buffer, semaphore, etc), then return. Leave thread waiting on suspensionEvent as part of resource wait
// else pulseEvent (suspensionEvent)

STOP_SELF
// error checks
// if error process, reset HM error queue
// restartThread - run 653 preamble so it is at a suspension event waiting for start

STOP
// error checks
// cancel any pending resource waits
// if error process current and stopping the preempted process, ensure user level preemption lock is reset to 0
// restart thread so it gets back to waiting at suspension event for start

START
// error checks
// if aperiodic
   // if in NORMAL mode
      // setup deadline based on current time + time capacity    (Is this something priority scheduler will track?)
      // pulse suspension event so it starts
   // if in startup
      // stays waiting on event until Normal mode
// else if periodic
   // if in NORMAL mode
      // Need to calculate next release point. Assume this is something 653 lib needs to do and is not part of priority scheduler. Also deadline can be calculated here
      // Some future window activation needs to check if release point and pulse suspension event

DELAYED_START
// NOT IMPLEMENTED. Not part of Honeywell SOW. May be able to calculate which future window would be release point.

LOCK_PREEMPTION
// error checks
// setThreadPriority(+1 of user range)
  // Note this is inadequate for multi-core.

UNLOCK_PREEMPTION
// error checks
// nesting logic
// setThreadPriority (restored), may schedule higher priority pending during that time. 
// Spec does not indicate that this has to be a yield, but it does not preclude that.

GET_MY_ID
// some error checks for initial/error process
// return 653 handle

GET_PROCESS_ID
// error checks
// return 653 handle for named process

GET_PROCESS_STATUS
// error checks
// copy static info
// If current thread, state = RUNNING. Else runtime should know if WAITING, READY, or DORMANT. Should we ask somehow to know if WAITING vs READY not by 653 API. ie. User calls Deos API directly for some resource.

TIMED_WAIT
// if DELAY = 0, setThreadPriority(same) causing yield
// waitForEvent (threadSuspensionEvent, timeout) (How is timeout validated for range and passed through?)

PERIODIC_WAIT
// error checks
// calculate next release point as current release point + period
// calculate new deadline time as next release point + time capacity (who is responsible for monitoring and reporting this)
// waitForEvent (threadSuspensionEvent) timeout used for release point, or preferably waitIndefinite there but windowActivation pulses. (This may be able to use startOfPeriod events and Deos long duration syntax)

GET_TIME
// calls PAL getElapsedTimeInNs

REPLENISH
// error checks - periodic process cannot exceed next release point
// update deadline time currently in effect  (how does 653 request this of the scheduler if that can use thread timer as current 653 process deadline monitor?)

WINDOW_WAIT - DDC-I extension
// allows better continuation slice usage, and aperiodic process to wait for known event rather than timed wait
// waitForEvent (threadSuspensionEvent)   - window activation must release all of these every activation but this approach 653 lib must pulse multiple events rather than a O(1) mergeList.

CREATE_BLACKBOARD
{
   // Error checks
   // createEvent to use for synchronizing
   // create blackboard 653 data structure
}

DISPLAY_BLACKBOARD
{
   // find blackboard
   // error checks
   // enter scheduler critical
   // copy data in and set occupied flag (should copy be in critical, or do we need another sync mechanism)
   // pulseEvent (Problem here is that if another thread suspended one of the waiters, they should also be waiting on their thread suspension event and should not wake up. Can we have thread waiting on multiple resources? If not, then we would need to use suspension event for this and loop pulsing them all.
   // leave scheduler critical
}

READ_BLACKBOARD
{
   // find blackboard
   // error checks
   // If blackboard has data, copy it.  Do we need to protect data not changing during copy?
   // Else if timeout = 0, return not available status
   // Else if preemption disabled by user or error process, return invalid mode
   // else if timeout would overflow, return error   (How do we know this now? Currently we convert to absolute ns time, compare with PAL max supported time
   // else (wait indefinite or valid timeout) waitForEvent   (How do we pass timeout, and can that wait know about the overflow and return status?)
   // If times out, then return timeout status
   // Else copy the buffer. Again do we need to protect data not changing during the copy?
}

CLEAR_BLACKBOARD
{
   // find blackboard
   // error checks
   // set flag blackboard is empty
}

GET_BLACKBOARD_ID
{
   // find blackboard, return handle
}

GET_BLACKBOARD_STATUS
{
   // find blackboard
   // error checks
   // get static max msg size, and dynamic empty indicator
   // TBD: Need to know how many threads waiting on the event. Does API Library need to keep track of that? 653 no processes are deleted, except on warm start so we could keep parallel consistent list with all calls to waitForEvent, pulseEvent.
}

CREATE_BUFFER
{
   // Error checks
   // create buffer 653 data structure, store queue discipline
   // No separate sync event. Uses a suspension event created as part of CREATE_PROCESS
}

SEND_BUFFER
{
   // find buffer
   // error checks
   // enter scheduler critical
   // If not full
      // If has waiting process, copy data to waiting threads stored address, pulseEvent (653 process suspension event, if 653 process not suspended)
      // Else, copy data to buffer.
   // Else if full
      // If no wait, return not available
      // if preemption user locked or error process, return error
      // Insert in 653 managed queue by discipline
      // store address allow read to copy our data without context switch to us.
      // waitForEvent (653 process suspension event) with timeout (who validates timeout)
      // when return either timed out or data was copied
}

RECEIVE_BUFFER
{
   // find buffer
   // error checks
   // If buffer has data
      // read first message.
      // If waiting sender, copy data into freed message, pulseEvent if thread not 653 suspended
   // Else if timeout = 0, return not available status
   // Else if preemption disabled by user or error process, return invalid mode
   // else (wait indefinite or valid timeout) waitForEvent (thread suspension event)
   // If times out, then return timeout status
   // Else buffer was copied into our pointer
}

GET_BUFFER_ID
{
   // find buffer, return handle
}

GET_BUFFER_STATUS
{
   // find buffer
   // error checks
   // get static and dynamic properties
   // Get num waiting (either empty or full)
}

Library Initialization
// ioi_init

Formatting functions
// knows data layout and does timestamp marking/freshness checking

CREATE_SAMPLING_PORT
// error checks
// ioi_open

WRITE_SAMPLING_MESSAGE
// error checks
// ioi_write

READ_SAMPLING_MESSAGE
// error checks
// ioi_read

GET_SAMPLING_PORT_ID
// error checks and find sampling port

GET_SAMPLING_PORT_STATUS
// find port
// get static data and last msg valid

Notes:
Queuing Ports
- Because POSIX apps should be able to use 653 API for sampling/queueing ports we want that to be in separate lib, or allow POSIX to bring in full 653 lib
- Sampling ports are no problem
- Queueing ports have issue with blocking
- If need to block, there is a queuing discipline which IOI does not support, so IOI or lib must deal with it.
- Problem is once port is available (not empty or full based on direction) notifying the next thread from queue to read/write the next message
- If multiple writers from different processes/windows we cannot guarantee that thread will be next to run, if we wanted to support freeing multiple spots in the port.

CREATE_QUEUING_PORT
// error checks
// save queue discipline
// ioi_open

SEND_QUEUING_MESSAGE
// error checks
// if no waiting processes
//   attempt ioi_write
//   if successful return status, else fall through
// if no timeout, return not available
// if user preemption or error process return invalid mode

(How does this work in FACE POSIX? 
   1) We don't want window activation to be this complex.
   2) 653 lib cannot assume current thread is 653 process with stored pointer to write from.
   3) If not 653 process, do we force POSIX pthread_create to create this object. Once this is a separate library, should RMA allow to call or that still does the IOI manually and does not play in queue discipline?

// Current implementation
   // waitForEvent (threadSuspensionEvent, timeout)
   // At window activation, scheduler sees if any pending IOI writes and it attempts them itself, since it knows where the 653 calling process has the data and if successful releases 653 process

// New implementation
   // If FIFO queue discipline, setThreadPriority (user max + 1) so it will run FIFO order to read the port
   // waitForEvent (threadSuspensionEvent, timeout)
   // At process switch (for POSIX may be within same window) if thread is waiting for ioi pulse threadSuspensionEvent. (We currently don't have process switch notification, only window activation)
   // Thread wake up check timeout expired and if not do ioi_write. If not successful loop waiting for event with reduced timeout.
   // Restore priority if necessary, which may schedule away

// Preferred new implementation
   // If FIFO queue discipline, setThreadPriority (user max + 1) so it will run FIFO order to read the port
   // ioi_timedwrite - ioi deals with keeping list of threads to block waitForEvent with timeout, and ioi_read will pulseEvent for the next in queue
   // restore priority if we switched it to use FIFO rather than priority

   // The problem with this approach is if we have multiple writers from different windows, ioi would have to wait for the ioi_write to come from the pulsed thread, before it could have ioi_read signal any others.
   // Therefore, it would need to know if it released any writes which have not happened, then the ioi_write would trigger the next release for an ioi_write.
   // That could cause synchronization issues if a thread is pulsed but then never makes its write

FACE Project

Description

Work packet notes

Documentation

FACE Profiles

POSIX API's

Concerns when designing within new Deos kernel paradigm

653 Questions

POSIX questions

Permissions

Clocks/Timers

Message Queues

PThreads

Condition Variables

Mutex

Semaphores

Memory Objects

Signals

File System

653 Pseudo Code Analysis

Partition API

Process API

Time API

Blackboard API

Buffer API

Event API

Semaphore API

Sampling Port API

Queuing Port API

Face to face meetings

August 2013, Alexandria, VA

Multi-core

September 2013, Tucson, AZ

Navigation menu

Search