Cooperative Software Systems
Home Products Company Contacts News Licensing















Multi-Threading Has a Shadow

When you start a thread of execution what you are really doing is starting a backend-process (some operating systems call threads light-weight processes.) Think of a backend-process as something taking place in another room of your house. You're sitting in the den and the new thread is working in the basement. What is it doing down there? Is it still alive? What happened to the last request I asked it to work on?

Every backend-process needs to address these common threading issues:

  • What if a thread hangs in a never-ending loop?
  • What if a thread abnormally terminates?
  • What if a thread needs a new thread itself?
  • What if the thread create/destroy overhead bogs down the application processing?
  • What if a thread needs timing?
  • What if a thread needs canceling?
    This is the thread overload problem (i.e. where so many threads are executing that the System cannot sustain anymore threads or these threads cause so much competition for resources that the environment effectively stalls.)
  • What if the System cannot handle any more threads? (sidebar)
  • What is the status of the current request?
  • What is the status of a prior request?
  • Where is the congestion?
  • How to notify someone when an error occurs in a thread?
  • How to detect and recover from stalls?
  • How to tune this multi-threading environment?
  • How can we inquire about the health of the environment?
  • How may the threading environment quiesce and shut down gracefully?

Multi-Threading has been around for a long time. Developers have been answering these questions with in-house and proprietary software for decades. The key to handling these problems is to build a backend process manager.

The way to building a backend-process manager is:

  • to separate the threading logic from the application logic,
  • to individually control each thread and
  • to build GUI and non-GUI interfaces into the environment.

That sounds simple enough. At least until we try it. A mission-critical, backend-process manager must answer all the common threading issues, above, and have the ability to handle:

  • components (a request with multiple parts),
  • recursion (when nested levels of access are necessary),
  • persistence (for shared objects between threads),
  • run-time alteration (to provide a dynamic response to an ever changing environment.),
  • extensions to the base logic (start-up/shutdown  hooks and exits),
  • logging (of errors and events),
  • and, never forget debugging.

Welcome to Tymeac, the backend process manager.


Tymeac is a trademark of Cooperative Software Systems


1998 - 2016 Cooperative Software Systems  All rights reserved.