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.
