Threading

Thread types

PLMS uses the following threads to handle processes. Each thread type performs specific functions:

• Main thread - creates the Controller thread and the Client thread.
• Controller thread - dequeues actions from action_queue and changes the state of the component as a result of the action.
• Client handler thread - handles commands from external applications and queues the actions in action_queue.
• Worker thread - starts and stops components.
• Pulse handler thread - handles two types of pulses from QOS: the DEATH notification pulse, and the PATH SPACE notification pulse.
• Watchdog thread - monitors the heartbeat of all clients at the specified interval.

Main thread

The main thread is responsible for creating the controller thread and the client thread. In addition to parsing and validating command line arguments, the main thread context parses the initial configuration file (provided as a command line argument).

If the parsing of the initial configuration file is not successful, the main thread aborts plms execution. After successful parsing of the initial configuration file and creation of the initial action, the main thread enters the signal handler routine.

Controller thread

The controller thread is the only thread that dequeues actions from action_queue and changes the state of the component as a result of the action.

By serializing all actions through the controller thread, the order of actions is maintained, and less synchronization between threads is required.

The main activities of the controller thread are:

• The controller thread waits for an action to be added to the action_queue in order to process the action. If an action is available and a worker thread is available, the controller thread assigns the action to the worker thread.
  • If all worker threads are busy processing actions, it waits for at least one worker thread to return to continue processing the queue.
• The controller thread ensures that the same component is not assigned to multiple worker threads at the same time. In the scenario where two actions for a component are queued, the controller thread avoids dequeuing them both and assigning them to different worker threads, which would put the component in an inconsistent state.
• If a worker thread is processing the component, then the controller threads skips the current action and selects the next action in the queue to process. The skipped action is marked so that when a busy worker thread returns, queue processing will start from the skipped component; this is necessary to maintain the order of actions to be processed. When a processing reaches the tail of the queue, queue processing restarts from the head of the queue.
• If an action has been completed, the controller thread deletes the action. If a component has changed state based on the current action, the controller thread handles moving the component to a particular state. If the component is marked to send a notification of state change, the controller thread calls the Notifier API to send the notification. If an action requires further actions to be created for the dependent components, controller threads create the actions and queue them in the action_queue.
• The controller thread calculates the minimum wait time to process the actions. An action on a component may trigger a waitfor condition.
• If the condition checking needs to be delayed, the controller thread calculates the minimum wait time of all waitfor conditions and waits for the minimum timeout. Since the controller thread handles the main functionality of PLMS, the PLMS heartbeat is sent from the controller thread.
• If a controller thread hangs for any reason, the PLMS heartbeat is not executed, and a system manager application can detect the PLMS heartbeat failure and take a recovery action.

Client handler thread

The client handler thread (resource manager thread) is responsible for handling commands from external applications and queueing the actions in action_queue.

Worker thread

The main activity of worker threads is to start and stop components. The worker threads call the executor to perform the tasks and functions of a component for the given action.

Pulse handler thread

The pulse handler thread handles two types of pulses from QOS: notification pulses and path space pulses. The death notification pulse detects if any processes started by PLMS have died and then creates the appropriate actions for addition to the action_queue. The path space notification pulse detects when a new file is added to the path space and releases the component waiting for the file.

Watchdog thread

The watchdog thread monitors the heartbeat of all clients at the specified interval. If the watchdog thread detects a heartbeat failure for a component, it disables monitoring and creates a fail action for the component and queues it in action_queue.