Friday, November 11, 2011

Multi-Queue Or FSM ThreadPool, Could This Be A New Design Pattern

ThreadPool Introduction
      As we all know that normal ThreadPool contains the number of threads and all those threads takes the tasks from the single common queue present in the ThreadPool. But in this type of thread pool we cannot ensure the order of processing of the tasks present in the queue. These thread pool are best where we do not have any dependency on the other task(s) present in the queue.
      But there are certain applications that requires that the order of the processing of the Tasks should be maintained in which they came/arrive in the application. When Application wants to maintain the order of the events/tasks when processing them. If we use the normal ThreadPool in this case, this will not work as it does not ensure the task processing order.

What is Multi-Queue Or FSM(Finite State Machine) ThreadPool
      As we discussed above, where normal ThreadPool fails. So I though of a multi-queue ThreadPool which maintains the sequence of the tasks in which they came and process those tasks in the specified order only.
      If we see any FSM (Finite State Machine), we generally describe the flow of the machine using FSM. In FSM, flow normally goes from one state to another state and in Mealy Machines result depends on the input provided and current state of machine.
      If we have some objects in our application that have some states associated with that object and that can be changed based on the input and its current state, in this condition we must use the FSM-ThreadPool to solve our problem.
      FSM ThreadPool can only be used in your application, if your objects are changing their states based on some inputs/events/tasks which is being/to-be processed by the ThreadPool.
Key Elements of FSM ThreadPool
  • KeyObject (KO): Object which is keep on changing its state and it's state change should be processed sequentially.
  • StateChangeTask (SCT/Task): Task to be performed to change the state of the KO.
Every SCT/Task must have the information to identify its KO.

When you need the FSM ThreadPool
  • When you are having some decoupled systems
  • These decoupled systems communicates in asynchronous manner via events/messages.
  • When you actually wanted to process the events/messages in the order they arrive in the systems from other system.
  • When each state change on a specific object(KO) is treated independently.

How FSM-ThreadPool works
      Well, in simple ThreadPool we have many threads running or in IDLE state, those takes tasks from a single common queue. But in FSM ThreadPool we have many threads and multi-queue concept. We manage the multiple queues and multiple Threads those will take the tasks from the queue and process them.

FSM ThreadPool

      Why we need the multi-queue here? As we have discussed above that there can be many KOs in your application and their state change must be processed Sequentially. So if one KO is changing its state from x-> y and second KO is also changing its state from let say p->q then processing of the tasks of both the KO can be done simultaneously, as those objects are not dependent on each other. To maintain the sequence of the SCTs/Tasks processed on a KO we should handle them sequentially in a single queue. Our ThreadPool should be able to identify the unique KO associated with the SCT/Task and keep those SCT/Task into the same queue, so that those can be processed sequentially.

Multi-threading along with Sequential execution
Lets take an example of an application which is having multiple KOs

M0 => M0-T1, M0-T2, M0-T3 . . . . . . . . M0-Tn
M1 => M1-T1, M1-T2, M1-T3 . . . . . . . . M1-Tn

M0 and M1 are both KOs objects and their associated Tasks/SCTs in sequence are in the form M<ko-id>-T<taskseq>

As we can see that M0 and M1 both are independent of each other, they do not have any dependency. Those KO's behaviors are only dependent on their Tasks those are coming in sequential order. So it is possible that two separate threads T1 and T2 can process the tasks of M0 and M1 simultaneously.

Keep watching for this blog, to see the various implementations...

No comments:

Post a Comment