Está en la página 1de 4

Pregunta 1.

El static scheduling divide los trabajos de un proceso en partes iguales a los distintos procesadores.
Esta asignación no será cambiada durante toda la ejecución del programa.

Como la división de trabajos puede ser desigual existe el dinamic scheduling en el cual se la asigna
un trabajo a cada procesador, pero a medida que un procesador termina un trabajo, se le asigna
un nuevo trabajo. La idea de esto es que no queden nodos sobrecargados y la división de trabajo
sea más equitativa y así todo el proceso terminará más rápido, el problema es que hay un
overhead en la asignación dinámica de trabajos.

En el guided scheduling se asignan los trabajos en grupos (chunks) a cada procesador. Una vez que
el procesador termino todos estos trabajos ahí se le vuelve a asignar otro grupo de trabajos, de
forma que este grupo es más pequeño y así sucesivamente hasta terminar. El beneficio de esta
forma es que se tienen que hacer menos asignaciones durante la ejecución del programa y esto
nos ahorra tiempo, pero también utiliza cierto dinamismo, pues una vez terminados los chunks de
trabajos se asignan nuevos chunks más pequeños para mantener el balance de cargas de cada
procesador más o menos similar.

Un ejemplo podría ser una ejecución de un programa de backtracking largo donde se van
paralelizando ramas del árbol de back tracking. Este proceso podría ser muy largo y la duración de
cada expansión del árbol podría tener una variación muy variada. En este caso un group sharing
podría solucionar bien este problema, al reducir la asignación de trabajos y además dándole cierto
dinamismo a los procesos permitiendo que se divida mejor la carga.

Pregunta 2.

Tendremos que work sharing single hace que cierta sección de código sea ejecutada por solo 1
thread. Este nos es útil si por ejemplo ejecutamos una parte de cierto código que debe ser
secuencial y no puede dividirse. También puede ser si hay una edición de memoria crítica.

Un ejemplo puede ser un programa que tiene tareas de Input/Output como escribir sobre una
consola. Es posible que queramos escribir ciertos resultados, pero si lo hacemos en paralelo haría
que los resultados no fueran legibles, por lo mismo puede que sea buena idea utilizar work sharing
single para asegurar que ese output esté bien escrito y en cierto orden también.

Pregunta 3

Collapse es una cláusula que se le aplica a la directiva for. Esta permite que si tenemos for
anidados podemos paralelizar cosas que están más profundas dentro de un for. Un ejemplo de
esto puede ser si trabajamos con suma de matrices, por ejemplo.

Esto se puede hacer con 2 for anidados donde en lo más profundo se suman los valores de las
matrices A[i] = B[i] + C[i]. Todas estas sumas son independientes por lo que podemos paralelizar
dichas sumas. También se podría sumar trozos de filas ajustando los for (collapse nos permite
decir que tan profunda es la paralelización) y así aprovechamos mejor la memoria en común de
estas filas.

Pregunta 4

La cláusula shared nos indica que todo lo que está en el scope externo de la región paralela serán
compartidos dentro de la región paralela, mientras que la cláusula private nos dice que las
variables que había afuera serán privadas dentro de esta región paralela, no se comparten. Sin
embargo, estas quedaran no inicializadas.

Firstprivate sirve para hacer algo parecido a private, solo que ahora las variables serán inicializadas
con el valor que tenían antes de entrar a esta región paralela. Last private permite que una
variable privada que tomó cierto valor en la región paralela mantenga su valor al terminar la parte
paralela para luego poder acceder al valor de dicha variable.

El comportamiento por defecto es que la memoría será shared, ósea compartida. Esto solo aplica a
las variables definidas fuera del scope paralelo, las variables locales del scope paralelo serán
private.

Pregunta 5

a)

la salida del programa fue la siguiente:

O sea, una matriz de 6 * 15 de ceros. Esto pasa porque se llama a ala función fillcolumn(j) para j
desde 0 hasta 5. Como en este caso no tenemos paralelismo, si no secuencialidad, el for dentro de
fill columns, en cada iteración recorre todas las filas dentro de una columna y las asigna con 0 que
viene de omp_get_num_threads().
b) Lo que se imprime es lo siguiente:

Vemos que para la primera columna se ejecuta correctamente fill columns, en cada thread (son 5)
se ejecuta un pedazo del for, en particular se ejecutan 3 pasos del for en cada thread (el thread x
ejecuta desde i = 3x hasta i = 3(x+1))

Y aquí vemos que el for de fillcolumns no se recorre correctamente para las siguientes columnas, o
tendríamos que se habrían registrado cambios en las columnas completas. Lo que crea este
comportamiento es que tenemos 2 las siguientes directivas/clausulas seguidas

#pragma omp parallel for num_threads(NCOLS - 1)


#pragma omp for
Ya estamos dentro de un omp for, por lo que si intentamos llamar nuevamente un omp for solo
tendremos acceso al thread dentro del que ya estamos. Habría que hacer cambios en las directivas
(permitir nested paralelism) para que el for dentro del fillColumn se ejecute en su totalidad.

Pregunta 6

a) El objetivo de este código es hacer sumas dentro de 2 arrays. Estos arrays requieren
realizar sumas y multiplicaciones, podemos ver que se realizan en estos for de folma
alternada sumas y multiplicaciones. Esto podría mejorar un poco la rapidez del programa
el hecho de alternar suma y multiplicación si es que existen componentes separados para
realizar suma y multiplicación, sin embargo, no pareciera algo muy claro.

b) Si es posible que se genere un deadlock. En las líneas 25 y 37 se hace un lock de locka y


lockb, siendo estos tramos paralelos diferentes, por lo que podrían coincidir. Si es que
coinciden, podemos ver que el primer tramo no podrá avanzar de la línea 28, pues quiere
hacer lock de lockb pera esta bloqueada por el segundo tramo. Similarmente para el
segundo tramo, este quiere hacer lock de locka en la línea 40, sin embargo el tramo 1
tiene bloqueado a locka y por ende este tramo tampoco podrá avanzar y así es como
llegamos a un deadlock.

También podría gustarte