Rather than a traditional walk-through of how to code, this will be more of a flow-chart to determine which type of parallel processing paradigm to use, if any:

• How large is your dataset? If your dataset is small (based on your experience), then a single-threaded process may not hurt you too much.
• Can your data processing and logic flow be split into simultaneous operations? Frequently, the type of program and the data being worked on simply don't allow for any type of concurrency or parallel programming.

• Is your processing CPU-limited or I/O-limited? CPU-intensive applications are best met with multiprocessing whereas I/O-intensive applications are handled better with multithreading.
• Do you need to have a shared memory pool? In a shared memory pool, you have to make sure that each data request doesn't occur at the same time as a data write, that is, a race condition, so locking each data transaction is necessary. Non-shared memory requires the creation of communication calls between threads/processes if data transfer is required.
• Have you identified where the bottlenecks are? Before you design a parallel program, you have to find the troublespots within the process. While you can parallelize the whole program, you get a better return if you focus on optimizing the data bottlenecks and functions that do most of the work.