Thread transparency in information flow middleware

  • Authors:

  • Rainer Koster;Andrew P. Black;Jie Huang;Jonathan Walpole;Calton Pu

  • Affiliations:

  • Fachbereich Informatik, Universität Kaiserslautern, Postfach 3049, 67653 Kaiserslautern, Germany;Department of Computer Science and Engineering, OGI School of Science and Engineering, Oregon Health and Science University, 20000 NW Walker Road, Beaverton, OR;Department of Computer Science and Engineering, OGI School of Science and Engineering, Oregon Health and Science University, 20000 NW Walker Road, Beaverton, OR;Department of Computer Science and Engineering, OGI School of Science and Engineering, Oregon Health and Science University, 20000 NW Walker Road, Beaverton, OR;College of Computing, Georgia Institute of Technology, Atlanta, GA

  • Venue:
  • Software—Practice & Experience - Special issue: Middleware
  • Year:
  • 2003

Quantified Score

Hi-index 0.00

Visualization

Abstract

Applications that process continuous information flows are challenging to write because the application programmer must deal with flow-specific concurrency and timing requirements, necessitating the explicit management of threads, synchronization, scheduling and timing. We believe that middleware can ease this burden, but many middleware platforms do not match the structure of these applications, because they focus on control-flow centric interaction models such as remote method invocation. Indeed, they abstract away from the very things that the informatian-flow centric programmer must control.This paper describes Infopipes--a new high-level abstraction for information flow applications--and a middleware framework that supports them. Infopipes handle the complexities associated with control flow and multi-threading, relieving the programmer of these tasks. Starting from a high-level description of an information flow pipeline, the framework determines which parts of a pipeline require separate threads or coroutines, and handles synchronization transparently to the application programmer. The framework also gives the programmer the freedom to write or reuse components in a passive style, even through the configuration will actually require the use of a thread or coroutine. Conversely, it is possible to write a component using a thread and know that the thread will be eliminated if it is not needed in a pipeline. This allows the most appropriate programming model to be chosen for a given task, and existing code to be reused irrespective of its activity model.