3.3.6.5 Master–Slave or Master–Worker In the SIMD and SPMD models, all threads have equal rights. In the master–slave model, also called master–worker model, there is one master which controls the execution of the program. The master thread often executes the main function of a parallel program and creates worker threads at appropriate program points to perform the actual computations, see Fig. 3.5 (left) for an illustration. Depending on the specific system, the worker threads may be created statically or dynamically. The assignment of work to the worker threads is usually done by the master thread, but worker threads could also generate new work for computation. In this case, the master thread would only be responsible for coordination and could, e.g.,perform initializations, timings, and output operations. Fig. 3.5 Illustration of the master–slave model (left) and the client–server model (right). 3.3.6.6 Client–Server The coordination of parallel programs according to the client-server model is similar to the general MPMD (multiple-program multiple-data) model. The client–server model originally comes from distributed computing where multiple client computers have been connected to a mainframe which acts as a server and provides responses to access requests to a database. On the server side, parallelism can be used by computing requests from different clients concurrently or even by using multiple threads to compute a single request if this includes enough work. When employing the client–server model for the structuring of parallel programs, multiple client threads are used which generate requests to a server and then perform some computations on the result, see Fig. 3.5 (right) for an illustration. After having processed a request of a client, the server delivers the result back to the client. The client–server model can be applied in many variations: There may be several server threads or the threads of a parallel program may play the role of both clients and servers, generating requests to other threads and processing requests from other threads. Section 6.1.8 shows an example for a Pthreads program using the client–server model. The client–server model is important for parallel programming in heterogeneous systems and is also often used in grid computing and cloud computing. 3.3.6.7 Pipelining The pipelining model describes a special form of coordination of different threads in which data elements are forwarded from thread to thread to perform different processing steps. The threads are logically arranged in a predefined order, T1, . . . , Tp, such that thread Ti receives the output of thread Ti−1 as input and produces an output which is submitted to the next thread Ti+1 as input, i = 2, . . . , p − 1. Thread T1 receives its input from another program part and thread Tp provides its output to another program part. Thus, each of the pipeline threads processes a stream of input data in sequential order and produces a stream of output data. Despite the dependencies of the processing steps, the pipeline threads can work in parallel by applying their processing step to different data. The pipelining model can be considered as a special form of functional decomposition where the pipeline threads process the computations of an application algorithm one after another. A parallel execution is obtained by partitioning the data into a stream of data elements which flow through the pipeline stages one after another. At each point in time, different processing steps are applied to different elements of the data stream. The pipelining model can be applied for both shared and distributed address spaces. In Sect. 6.1, the pipelining pattern is implemented as Pthreads program. 3.3.6.8 Task Pools In general, a task pool is a data structure in which tasks to be performed are stored and from which they can be retrieved for execution. A task comprises computations to be executed and a specification of the data to which the computations should be applied. The computations are often specified as a function call. A fixed number of threads is used for the processing of the tasks. The threads are created at program start by the main thread and they are terminated not before all tasks have been processed. For the threads, the task pool is a common data structure which they can access to retrieve tasks for execution, see Fig. 3.6 (left) for an illustration. During the processing of a task, a thread can generate new tasks and insert them into the task pool. Fig. 3.6 Illustration of a task pool (left) and a producer-consumer model (right)

3.3.6.5 Maestro – esclavo o maestro – trabajador En los modelos SIMD y SPMD, todos los subprocesos tienen los mismos derechos. En el modelo maestro-esclavo, también llamado modelo maestro-trabajador, hay un maestro que controla la ejecución del programa. El hilo maestro a menudo ejecuta la función principal de un programa paralelo y crea hilos de trabajo en los puntos apropiados del programa para realizar los cálculos reales, vea la figura 3.5 (izquierda) para una ilustración. Dependiendo del sistema específico, los subprocesos de trabajo pueden crearse de forma estática o dinámica. La asignación de trabajo a los subprocesos de trabajo normalmente la realiza el subproceso maestro, pero los subprocesos de trabajo también podrían generar un nuevo trabajo para el cálculo. En este caso, el hilo maestro solo sería responsable de la coordinación y podría, por ejemplo, realizar inicializaciones, temporizaciones y operaciones de salida. Fig. 3.5 Ilustración del modelo maestro-esclavo (izquierda) y el modelo cliente-servidor (derecha). 3.3.6.6 Cliente – Servidor La coordinación de los programas paralelos según el modelo cliente-servidor es similar al modelo general MPMD (programa múltiple de datos múltiples). El modelo cliente-servidor proviene originalmente de la computación distribuida en la que se han conectado múltiples computadoras cliente a un mainframe que actúa como un servidor y proporciona respuestas a las solicitudes de acceso a una base de datos.En el lado del servidor, el paralelismo se puede usar al computar las solicitudes de diferentes clientes al mismo tiempo o incluso al usar múltiples subprocesos para calcular una sola solicitud si esto incluye suficiente trabajo. Cuando se emplea el modelo cliente-servidor para la estructuración de programas paralelos, se utilizan varios subprocesos de clientes que generan solicitudes a un servidor y luego realizan algunos cálculos sobre el resultado; consulte la Fig. 3.5 (derecha) para ver una ilustración. Después de haber procesado una solicitud de un cliente, el servidor devuelve el resultado al cliente. El modelo cliente-servidor se puede aplicar en muchas variaciones: puede haber varios subprocesos del servidor o los subprocesos de un programa paralelo pueden desempeñar el papel de clientes y servidores, generando solicitudes a otros subprocesos y procesando solicitudes de otros subprocesos. La sección 6.1.8 muestra un ejemplo de un programa Pthreads utilizando el modelo cliente-servidor. El modelo cliente-servidor es importante para la programación paralela en sistemas heterogéneos y también se usa a menudo en la computación en grid y en la computación en la nube. 3.3.6.7 Canalización El modelo de canalización describe una forma especial de coordinación de diferentes subprocesos en la que los elementos de datos se envían de un subproceso a otro para realizar diferentes pasos de procesamiento. Los hilos se organizan lógicamente en un orden predefinido, T1,. . ., Tp, tal que el hilo Ti recibe la salida del hilo Ti − 1 como entrada y produce una salida que se envía al siguiente hilo Ti + 1 como entrada, i = 2,. . . , p - 1. El subproceso T1 recibe su entrada de otra parte del programa y el subproceso Tp proporciona su salida a otra parte del programa. Por lo tanto, cada uno de los hilos de la tubería procesa un flujo de datos de entrada en orden secuencial y produce un flujo de datos de salida. A pesar de las dependencias de los pasos de procesamiento, los subprocesos de la tubería pueden funcionar en paralelo aplicando su paso de procesamiento a datos diferentes. El modelo de canalización puede considerarse como una forma especial de descomposición funcional en la que los hilos de la tubería procesan los cálculos de un algoritmo de aplicación uno tras otro. Una ejecución paralela se obtiene al dividir los datos en un flujo de elementos de datos que fluyen a través de las etapas de la tubería una tras otra. En cada momento, se aplican diferentes pasos de procesamiento a diferentes elementos del flujo de datos. El modelo de canalización puede aplicarse tanto para espacios de direcciones compartidos como distribuidos. En la sec. 6.1, el patrón de canalización se implementa como programa Pthreads. 3.3.6.8 Grupos de tareas En general, un grupo de tareas es una estructura de datos en la que se almacenan las tareas a realizar y de las cuales se pueden recuperar para su ejecución. Una tarea comprende los cálculos que deben ejecutarse y una especificación de los datos a los que se deben aplicar los cálculos.Los cálculos a menudo se especifican como una llamada de función. Se utiliza un número fijo de subprocesos para el procesamiento de las tareas. Los hilos se crean en el inicio del programa por el hilo principal y se terminan no antes de que se hayan procesado todas las tareas. Para los subprocesos, el grupo de tareas es una estructura de datos común a la que pueden acceder para recuperar tareas para su ejecución; consulte la Fig. 3.6 (izquierda) para ver una ilustración. Durante el procesamiento de una tarea, un subproceso puede generar nuevas tareas e insertarlos en el grupo de tareas. Fig. 3.6 Ilustración de un grupo de tareas (izquierda) y un modelo productor-consumidor (derecha)