Content uploaded by Alejandro Valero
Author content
All content in this area was uploaded by Alejandro Valero on Jun 06, 2019
Content may be subject to copyright.
Atomicidad, Consistencia, Paralelismo y
Concurrencia en un Trazador de Rayos
elaborado a lo largo del Grado en
Ingenier´
ıa Inform´
atica
Alejandro Valero, Dar´
ıo Su´
arez Gracia, Rub´
en Gran, Adolfo Mu˜
noz, Joaqu´
ın Ezpeleta,
Jos´
e Luis Briz, Luis M. Ramos, Ana C. Murillo, Eduardo Montijano,
Javier Resano, Mar´
ıa Villarroya-Gaud´
oyV´
ıctor Vi˜
nals1
Resumen
— Para el alumnado de Ingenier´
ıa Inform´
atica resulta
de gran inter´
es alcanzar una visi´
on global de los diferentes niveles
de abstracci´
on que permiten entender y explotar un sistema
inform´
atico. Sin embargo, la organizaci´
on habitual del Grado de
Ingenier´
ıa Inform´
atica en asignaturas tiende hacia la creaci´
on
de compartimentos estancos, donde se suele trabajar con un
´
unico nivel de abstracci´
on, lo cual conlleva a aislar conceptos y
especializar plataformas. Con el objetivo de dotar a un conjunto de
asignaturas de una mayor transversalidad, este art´
ıculo describe un
proyecto consistente en un trazador de rayos paralelo que permite
al alumnado experimentar las propiedades de la atomicidad,
consistencia, paralelismo y concurrencia de un sistema inform´
atico
desde el nivel algor´
ıtmico de una aplicaci´
on hasta las instrucciones
de c´
odigo m´
aquina, incluyendo la interacci´
on entre los diferentes
niveles de abstracci´
on del sistema y la relaci´
on con las asignaturas
involucradas. El desarrollo del proyecto se sustenta con la
elaboraci´
on de diferentes enunciados de pr´
acticas atendiendo a
los distintos niveles de abstracci´
on. Finalmente, se describen los
requisitos hardware y software necesarios para el desempe˜
no de
las pr´
acticas as´
ı como la justificaci´
on de la elecci´
on del dispositivo
Raspberry Pi como plataforma ´
unica de desarrollo.
Palabras clave
— Innovaci´
on docente, niveles de abstracci´
on,
proyecto transversal, Raspberry Pi, sistema inform´
atico.
I. INTRODUCCI´
ON
LA
ingenier
´
ıa Inform
´
atica utiliza el principio de
abstracci
´
on como mecanismo principal para construir
sistemas inform
´
aticos, que se utiliza en todos los
niveles. La abstracci
´
on pretende ocultar todos los
detalles innecesarios en el contexto de un nivel concreto,
estableciendo unas fronteras muy claras entre las distintas
partes de un sistema, que en muchos casos establecen
divisorias entre asignaturas habituales en un Grado en
Ingenier
´
ıa Inform
´
atica como el de la Universidad de
Zaragoza (UNIZAR).
Estas divisiones tan marcadas entre asignaturas pueden
ayudar al proceso de aprendizaje, puesto que centran
al alumnado en los aspectos clave que debe aprender.
Sin embargo, la experiencia tambi
´
en advierte que los
estudiantes pueden perder el contexto general y la visi
´
on
global del sistema inform
´
atico. El riesgo es que el
alumnado no sea capaz de integrar conceptos por s
´
ı
mismo y termine percibiendo algunas asignaturas como
compartimentos estancos sin relaci´
on entre s´
ı.
Algunos Trabajos de Fin de Grado (TFGs) apuestan por
un esfuerzo de cohesi
´
on entre distintas materias y mitigan
en gran parte el riesgo de aislamiento. Sin embargo,
1
Dpto. de Inform
´
atica e Ingener
´
ıa de Sistemas, Universidad
de Zaragoza, e-mails:
{alvabre, dario, rgran, adolfo,
ezpeleta, briz, luisma, acm, emonti, jresano,
maria.villarroya, victor}@unizar.es.
Aplicación
Biblioteca
Sistema Operativo
ALMA
Fig. 1. Niveles de abstracci´
on abarcados en el proyecto.
muchos otros trabajos son muy espec
´
ıficos, lo cual, aunque
interesante, mantiene al alumnado alejado de la visi
´
on
global.
El presente art
´
ıculo, enmarcado en un proyecto
de innovaci
´
on docente, persigue la formaci
´
on de
profesionales e investigadores con la mencionada visi
´
on
de conjunto. Sin lugar a dudas, este perfil se valora
enormemente tanto en la industria como en la academia,
puesto que la visi
´
on de conjunto permite valorar riesgos,
liderar proyectos o abordar una formaci
´
on posterior
(especializada o no) con mayores garant´
ıas de ´
exito.
Como ejemplo motivador y conductor, este art
´
ıculo se
centra en conceptos muy importantes de la resoluci
´
on de
problemas con recursos m
´
ultiples, de forma correcta y
eficiente, presentes en un sistema inform
´
atico: atomicidad,
consistencia, paralelismo y concurrencia. El estudio de
estos conceptos involucra a varias asignaturas de la
titulaci
´
on. Sin embargo, al analizar los requisitos deseados
para la plataforma hardware a utilizar se han tenido en
cuenta necesidades de otras asignaturas de la titulaci
´
on,
que podr
´
ıan beneficiarse y formar parte de este u otros
proyectos relacionados en el futuro (Secci´
on IV-A).
El ejemplo elegido es un trazador de rayos
que utiliza colas concurrentes, las cuales pueden
emplear funciones de biblioteca basadas en mutexes o
llamadas al sistema futex implementadas directamente
en ensamblador. De este modo, como se aprecia
en la Figura 1, el proyecto abarca los niveles de
abstracci
´
on de Aplicaci
´
on, Biblioteca, Sistema Operativo
y Arquitectura de Lenguaje M
´
aquina (ALMA), e involucra
a cuatro asignaturas: Inform
´
atica Gr
´
afica, Programaci
´
on
de Sistemas Concurrentes y Distribuidos, Sistemas
Operativos y Multiprocesadores.
Para enlazar los niveles se elaboran enunciados de
Curso 1º Curso 2º Curso 3º Curso 4º
Estudios
comunes
Estudios comunes
Estudios optativos
TFG
Estudios de
especialidad
Fig. 2. Diagrama temporal del plan de estudios del Grado.
pr
´
acticas para cada asignatura y se presentan las directrices
principales que se han seguido y que permiten realizar
otros proyectos que busquen afianzar el aprendizaje
multinivel.
Cada sesi
´
on de pr
´
acticas se sit
´
ua en un nivel de
abstracci
´
on, pero como novedad, se a
˜
nade un contexto
referenciando al resto de niveles. Adem
´
as, para afianzar
la visi
´
on de conjunto, se emplea una plataforma
´
unica
en todas las sesiones de pr
´
acticas referentes al proyecto.
En este sentido, utilizamos Raspberry Pi [1] debido a
que, frente a otras plataformas, se trata de una soluci
´
on
de bajo coste que soporta virtualizaci
´
on y ejecuci
´
on
tanto con m
´
ultiples sistemas operativos de alto nivel
como sin sistema operativo (bare metal), entre otras
ventajas. Adem
´
as, varias universidades espa
˜
nolas han
utilizado recientemente este dispositivo para desarrollar
proyectos relacionados [2], [3], lo cual permitir
´
a compartir
experiencias de uso.
El resto del art
´
ıculo se organiza como sigue. La
Secci
´
on II introduce el contexto del Grado de Inform
´
atica
en el cual se pretende establecer el proyecto multinivel. La
Secci
´
on III describe el proyecto transversal propuesto.
La Secci
´
on IV presenta los requisitos tanto hardware
como software para llevar a cabo proyectos multinivel. La
Secci
´
on V muestra los resultados esperados, y finalmente,
la Secci´
on VI concluye el trabajo.
II. CON TEX TO DE L GRADO DE INGENIER´
IA
INFORM ´
ATICA EN UNIZAR
El Grado de Ingenier
´
ıa en Inform
´
atica en UNIZAR
1
es
una titulaci
´
on de cuatro cursos acad
´
emicos, 240 cr
´
editos
ECTS en total, que se imparte en la Escuela de Ingenier
´
ıa
y Arquitectura y en la Escuela Universitaria Polit
´
ecnica
de Teruel de la Universidad de Zaragoza. Como se puede
apreciar en la Figura 2, los primeros dos cursos y medio
son comunes para todos los alumnos y en ellos se estudian
la mayor parte de los conocimientos que cualquier
graduado en Ingenier
´
ıa Inform
´
atica debe aprender
2
. En el
a
˜
no y medio final se cursan dos asignaturas comunes, tres
optativas y ocho asignaturas de especialidad que permiten
a los estudiantes reforzar sus conocimientos en la tem
´
atica
que m
´
as les interese dentro de cinco opciones disponibles:
Computaci
´
on, Ingenier
´
ıa de Computadores, Sistemas de
Informaci
´
on, Tecnolog
´
ıas de la Informaci
´
on e Ingenier
´
ıa
del Software. Finalmente, el alumnado termina el Grado
realizando un TFG de 12 cr´
editos.
El Grado de Ingenier
´
ıa Inform
´
atica es una titulaci
´
on
1https://estudios.unizar.es/estudio/ver?id=148
2http://www.boe.es/boe/dias/2009/08/04/pdfs/
BOE-A- 2009-12977.pdf
muy pr
´
actica, donde la teor
´
ıa siempre se aplica a la
resoluci
´
on de problemas y al desarrollo de pr
´
acticas y
proyectos. Por ello, es tambi
´
en una titulaci
´
on con una
elevada carga de trabajo, si bien esta carga pr
´
actica es el
escenario ideal para asimilar los conceptos que se estudian
en las distintas asignaturas. En general, las pr
´
acticas
de cada asignatura se dise
˜
nan de forma independiente
para reforzar sus contenidos te
´
oricos, o coordin
´
andose
con las asignaturas que pertenecen a una misma
´
area
de conocimiento. Esto puede llevar a los estudiantes a
percibir una asignatura, o un grupo de asignaturas como
islas independientes, lo que dificulta que apliquen los
conocimientos adquiridos en cada una de ellas en su
carrera profesional. En realidad, estas divisiones son
puramente organizativas y de hecho todas las asignaturas
tienen muchas interacciones entre s´
ı.
Crear puentes entre asignaturas de distintas
´
areas es
fundamental para romper estas barreras y mejorar la
capacidad del alumnado para aplicar sus conocimientos.
Los resultados presentados en esta comunicaci
´
on
corresponden al trabajo realizado en dos proyectos de
innovaci
´
on docente donde profesorado de distintas
´
areas
de conocimiento y responsables de distintas asignaturas
han trabajado conjuntamente para facilitar la cohesi
´
on y
complementariedad de los diversos contenidos repartidos
en distintas asignaturas, en particular a trav
´
es de la
resoluci
´
on de un problema concreto de forma gradual
y mediante distintos enfoques.
III. PROP UESTA DE PROYECTO TRANSVERSAL
Esta secci
´
on presenta el proyecto conductor mediante
el cual los estudiantes podr
´
an disponer de una percepci
´
on
global de un sistema inform
´
atico. En primer lugar,
se presenta una visi
´
on general del sistema en niveles
de abstracci
´
on, incluyendo las asignaturas asociadas y
distribuci
´
on temporal en el Grado. La segunda parte
de esta secci
´
on ahonda en cada nivel de abstracci
´
on,
mostrando las interacciones entre niveles, objetivos
principales, as
´
ı como una descripci
´
on del material docente
desarrollado.
El material docente consiste en un enunciado de
pr
´
acticas por cada nivel de abstracci
´
on. Cada enunciado
se desarrolla en una sesi
´
on de dos horas de pr
´
acticas
en la asignatura asociada al nivel. Los enunciados se
encuentran disponibles en el repositorio p
´
ublico GitLab
de UNIZAR
3
, as
´
ı como para usuarios registrados en la
Sociedad SARTECO4.
A. Visi´
on General
Este proyecto permite al alumnado consolidar las
propiedades de atomicidad, consistencia, paralelismo y
concurrencia presentes en un sistema inform
´
atico t
´
ıpico.
En este caso, centramos el estudio en una aplicaci
´
on
basada en un trazador de rayos. La Figura 3 ilustra los
cuatro niveles de abstracci
´
on que constituyen el sistema,
3https://gitlab.unizar.es/alvabre/
proyecto-multidisciplinar.git
4http://sarteco.org/
repositorio-arquitectura- computadores/
universidades-colaboradoras- repositorio/
universidad-de- zaragoza/
proyecto-multidisciplinar/
informática
gráfica
prog. de sis.
concurrentes y
distribuidos
sistemas
operativos
multi-
procesadores
trazador rayos
Asignatura Actividad
cola concurrente con
exclusión mutua
exclusión mutua con
llamada sistema futex
exclusión mutua
en ensablador
niveles de abstracción
hardware software
Curso / Cuatrimestre
4º / Otoño
2º / Otoño
2º / Otoño
3º / Primavera
Fig. 3. Diagrama de niveles de abstracci´
on, asignaturas y curso.
as
´
ı como las asignaturas que han sido seleccionadas
dentro de la titulaci
´
on para afrontar el problema de forma
conjunta; para cada asignatura asociada a un nivel de
abstracci
´
on, la figura muestra el cuatrimestre y curso
acad´
emico en el cual se llevar´
a a cabo la actividad.
En el nivel de Aplicaci
´
on se implementa un algoritmo
de trazado de rayos en una sesi´
on de Inform´
atica Gr´
afica.
En esta actividad, las tareas a realizar sobre una imagen
se pueden paralelizar mediante la divisi
´
on de la imagen
en regiones. Estas regiones se asignan a distintos hilos
de ejecuci
´
on mediante una cola de tareas concurrente.
El segundo nivel, en la asignatura de Programaci
´
on de
Sistemas Concurrentes y Distribuidos, trata acerca de la
gesti
´
on de la cola de tareas con acceso concurrente por
parte de los hilos, la cual debe realizarse en exclusi
´
on
mutua y con espera condicionada. Se utilizar
´
an funciones
de la biblioteca pthread de POSIX para asegurar su
correcta gesti
´
on. En el tercer nivel, en el marco de
la asignatura de Sistemas Operativos, el acceso a la
regi
´
on de exclusi
´
on mutua se implementa con llamadas al
sistema operativo y primitivas at
´
omicas, sustituyendo as
´
ı
a las funciones de biblioteca. Finalmente, en el
´
ultimo
nivel, desarrollado en Multiprocesadores, se utilizan
instrucciones de c
´
odigo m
´
aquina para implementar la
exclusi
´
on mutua, pudiendo conseguir as
´
ı una mayor
eficiencia en rendimiento y consumo energ
´
etico frente
a las funciones de biblioteca y llamadas al sistema.
B. An´
alisis de los Niveles de Abstracci´
on Tratados
El sistema inform
´
atico objeto de estudio se presenta en
las siguientes secciones con un enfoque descendente, es
decir, empezando desde el nivel de Aplicaci
´
on hasta llegar
al nivel de ALMA. Cada secci
´
on se corresponde con una
pr
´
actica de una asignatura distinta. En la realidad, debido
a la distribuci
´
on de las asignaturas en cursos diferentes en
la titulaci
´
on, el desarrollo del proyecto no se puede llevar
a cabo de esta forma: comenzar
´
a en el nivel de Biblioteca
para descender hasta el de ALMA, dejando el nivel de
Aplicaci
´
on para el final. Consideramos que este orden,
impuesto por la planificaci
´
on temporal del Grado, es en
todo caso adecuado para el proceso de aprendizaje.
B.1 Trazador de Rayos Multihilo
Dos de las pr
´
acticas de la asignatura de Inform
´
atica
Gr
´
afica consisten en el dise
˜
no e implementaci
´
on de un
algoritmo cl
´
asico de trazado de rayos basado en una
c
´
amara estenopeica (v
´
ease Figura 4), junto con una versi
´
on
Fig. 4. C´
amara estenopeica del trazador de rayos.
m
´
as avanzada del mismo denominada path tracing [4].
El resultado de cada uno de los algoritmos es obtener
una imagen bidimensional a partir de una representaci
´
on
tridimensional de una escena virtual. Ambas pr
´
acticas
exigen al alumnado una serie de hitos m
´
ınimos junto con
varias tareas opcionales entre las cuales cada estudiante
elige una o m´
as para poder alcanzar la m´
axima nota.
En ambos algoritmos, la generaci
´
on del color de
cada p
´
ıxel de la imagen es independiente del resto
de p
´
ıxeles. Por tanto, dicha generaci
´
on es altamente
paralelizable a nivel de p
´
ıxel. Por ello, una estrategia
com
´
un para repartir la carga de trabajo es subdividir la
imagen en diferentes regiones (habitualmente cuadrados),
convirtiendo el c
´
alculo para cada una de las regiones en
una tarea a asignar a diferentes hilos de ejecuci
´
on. Sin
embargo, en la pr
´
actica y dependiendo de la escena y de
los diferentes detalles de implementaci
´
on de cada uno de
los algoritmos, la carga computacional puede variar mucho
de unas regiones a otras. Como es imposible estimar la
carga computacional de cada tarea, es necesaria una cola
de tareas de la cual cada uno de los hilos vaya extrayendo
y calculando la regi´
on de imagen asociada a la tarea.
En cada una de las dos pr
´
acticas (trazado de rayos
ypath tracing) los estudiantes deber
´
an paralelizar los
algoritmos utilizando una cola de tareas basada en la
pr´
actica presentada en la siguiente secci´
on.
B.2 Cola con Acceso Concurrente
Las colas, descritas en la asignatura de Estructuras de
Datos y Algoritmos, son un mecanismo muy adecuado
para la resoluci
´
on colaborativa de problemas en los
que varios procesos necesitan coordinarse. As
´
ı, de
manera natural, una arquitectura con productores y
consumidores puede utilizar una o varias colas para el
env
´
ıo de informaci
´
on (datos,
´
ordenes, etc
´
etera) entre los
productores y los consumidores. En este contexto de datos
compartidos, es necesario controlar el acceso concurrente
a la cola para preservar su integridad.
El objetivo de esta pr
´
actica es la implementaci
´
on de
una cola (limitada en tama
˜
no) con acceso concurrente
tanto para la inserci
´
on como la eliminaci
´
on de datos. El
hecho de ser de acceso concurrente y tambi
´
en limitada
presenta los dos aspectos fundamentales a considerar en
la sincronizaci
´
on: acceso en exclusi
´
on mutua y espera
condicionada.
Una primera tarea consistir
´
a en la implementaci
´
on y
adaptaci
´
on del tipo de cola limitada, de acuerdo a la
especificaci
´
on vista en la asignatura de Estructuras de
Datos y Algoritmos, de manera que pueda ser utilizada
para nuestro proyecto. Posteriormente, las operaciones
deber
´
an ser redise
˜
nadas con el fin de considerar los
aspectos de acceso concurrente: adem
´
as de asegurar
el acceso en exclusi
´
on mutua a la estructura de datos,
se deber
´
an implementar las operaciones de encolado y
desencolado como bloqueantes.
En las sesiones de teor
´
ıa se ha explicado la t
´
ecnica del
paso del testigo como una manera general de implementar
la instrucci
´
on gen
´
erica
<await B S>
(
B
es una guarda
booleana y
S
un bloque de instrucciones) mediante el uso
de sem
´
aforos binarios. Los estudiantes deber
´
an adaptar
el esquema general a la gesti
´
on de una cola usando
sem´
aforos binarios.
Se plantear
´
an dos versiones. Una primera en la que
el acceso a cualquier operaci
´
on de la cola ser
´
a en
exclusi
´
on mutua. Se plantear
´
a tambi
´
en una segunda
versi
´
on, con car
´
acter optativo, adaptando el esquema
de lectores/escritores al acceso a las operaciones de
una cola, de manera que para aquellas operaciones de
consulta (sin efectos laterales sobre la cola) se permite
el acceso simult
´
aneo de varios procesos (m
´
ultiples
lectores), mientras que se siga imponiendo acceso en
exclusi
´
on mutua para operaciones con efectos laterales
(
´
unico escritor), dando prioridad a los escritores. Ambas
versiones utilizan funciones de la biblioteca pthread para
implementar la regi
´
on de exclusi
´
on mutua de la cola. El
siguiente nivel trata acerca de c
´
omo implementar estas
funciones mediante servicios del sistema operativo.
B.3
Soporte a la Implementaci
´
on de la Cola con
Llamadas al Sistema
El objetivo principal de la pr
´
actica en este nivel
es doble. Por un lado, se espera que el alumnado
afiance el conocimiento acerca de la interacci
´
on existente
entre las funciones de biblioteca y el sistema operativo.
Por otro lado, se espera que el alumnado aprenda a
utilizar en concreto tanto la llamada al sistema futex
como las primitivas at
´
omicas
cmpxchg
y
atomic dec
para
implementar una regi´
on de exclusi´
on mutua.
El enunciado de pr
´
acticas de este nivel se basa en las
implementaciones de mutex propuestas por Drepper [5].
En primer lugar, describimos el funcionamiento y uso de
los par
´
ametros de la llamada al sistema futex
sys futex
.
Mediante el uso de esta llamada, se presentan dos
versiones distintas de algoritmos en pseudoc
´
odigo para
implementar las funciones de biblioteca relacionadas
con mutexes. La primera versi
´
on resulta intuitiva y
relativamente sencilla de implementar, mientras que la
segunda versi
´
on se trata del algoritmo m
´
as avanzado, m
´
as
eficiente y libre de cualquier comportamiento incorrecto
respecto a la primera versi´
on.
El Algoritmo 1 describe los procedimientos lock y
unlock para la versi
´
on avanzada de mutex. El valor de
la variable
val
representa el estado del mutex: mutex
libre (0), mutex bloqueado sin hilos esperando (1) y
mutex bloqueado con al menos un hilo esperando (2). El
procedimiento lock bloquea al hilo en ejecuci
´
on invocando
a la llamada al sistema futex en modo
futex wait
, siempre
y cuando el mutex est
´
e bloqueado, y dej
´
andolo en estado
Algorithm 1
Implementaci
´
on avanzada de lock yunlock
con la llamada al sistema futex.
1: int val =0
2: procedure LOCK
3: if (int c=cmpxchg(val, 0, 1) 6=0) then
4: do
5: if
(
c== 2||
cmpxchg(
val
, 1, 2)
6=0
)
then
6: futex wait(&val, 2)
7: end if
8: while (c=cmpxchg(val, 0, 2) 6=0)
9: end if
10: end procedure
11: procedure UNLOCK
12: if (atomic dec(val)6=1) then
13: val =0
14: futex wake(&val, 1)
15: end if
16: end procedure
de bloqueado con al menos un hilo esperando. En caso
contrario el hilo finaliza el procedimiento lock y toma
el mutex. En caso que varios hilos confluyan en el
procedimiento lock, solamente uno de ellos acceder
´
a,
mientras que el resto quedar
´
an bloqueados en una cola
del sistema al ejecutar
futex wait
. Por otro lado, el
procedimiento unlock libera el mutex y despierta a uno
de los hilos mediante la llamada al sistema futex en modo
futex wake.
El trabajo del alumnado consiste en analizar e
implementar ambas versiones de mutex a partir de los
algoritmos proporcionados, identificando las ineficiencias
y comprobando el funcionamiento incorrecto de la versi
´
on
simple frente a la versi
´
on avanzada. Adem
´
as, ambas
versiones deben sustituir a las funciones de biblioteca
utilizadas para la implementaci
´
on de la cola, comprobando
el correcto funcionamiento de la misma cuando utilizamos
la versi
´
on avanzada. Al final del trabajo, se proveer
´
a al
alumnado de un banco de pruebas para comparar las dos
implementaciones de la cola (con funciones pthread y
llamadas al sistema) en t
´
erminos de latencia y ancho de
banda variando la tasa de inserci´
on y consumo.
B.4 Implementaci´
on de Futexes en Ensamblador
Los servicios del sistema operativo para el acceso en
exclusi
´
on mutua a recursos compartidos, como en el
caso del futex, se apoyan en primitivas ofrecidas por la
ALMA. En el caso de ARM, estas primitivas pueden
ser accedidas directamente desde el nivel de usuario.
Esto puede explotarse para, sacrificando la comodidad
y seguridad ofrecidas por el sistema operativo, conseguir
una mayor eficiencia al evitar la sobrecarga de la llamada
al sistema.
Esta pr
´
actica proporciona o refuerza habilidades
pr
´
acticas para la programaci
´
on orientada al rendimiento
y a la eficiencia energ
´
etica. Adicionalmente, destaca la
importancia de disponer de un soporte adecuado en el nivel
de ALMA para que los mecanismos de mutex utilizados en
niveles de abstracci
´
on m
´
as complejos (Sistema Operativo,
Biblioteca y Aplicaci
´
on) sean eficientes. Finalmente,
acerca a las implicaciones que supone la implementaci
´
on
de bajo nivel, y contribuye a comprender la relaci
´
on entre
los modelos de memoria en alto nivel (e.g. C11) y los
modelos de consistencia en bajo nivel.
Persiguiendo estos objetivos, la pr
´
actica se estructura
en varios pasos. En cada paso, se facilita en el gui
´
on bien
la estructura del algoritmo a implementar, bien el c
´
odigo
para estudiar, revisar y completar.
En primer lugar se pide programar en C++ la
suma de los elementos de un vector mediante un
algoritmo de reducci
´
on de cuatro hilos, sin utilizar
primitivas de sincronizaci
´
on, a fin de comprobar
que produce resultados incorrectos. En un segundo
paso se pide programar una primitiva fetch and add
en ensamblador de ARMv8 mediante load-link/store-
conditional (
ldaxr/stlxr
), incorporarla al programa
anterior en C++, comprobar la correcci
´
on del resultado,
y razonar la diferencia en caso de haber utilizado
ldxr/stxr [6].
El tercer paso consiste en implementar una operaci
´
on
lock y otra unlock para implementar un mecanismo
de spin-lock. Este mecanismo podr
´
a ser directamente
utilizado para la implementaci
´
on de las colas concurrentes
utilizadas en las pr´
acticas anteriores.
Finalmente, se indica c
´
omo optimizar el consumo
energ
´
etico del spin-lock mediante instrucciones
wfe/sev
.
El estudiante puede adem
´
as observar que aunque se deja al
procesador suspendido en modo de bajo consumo durante
la espera, si
´
esta es muy breve puede continuar siendo
una espera activa desde el punto de vista del sistema
operativo (o biblioteca, si se implementa todo en modo
usuario), ya que no se planifica otro hilo durante la espera.
Sin embargo, si la suspensi
´
on excede por ejemplo el
timeslice del thread, puede comportarse como un sem
´
aforo
y provocar un cambio de contexto.
Tras esta pr
´
actica, el alumnado est
´
a en condiciones
de valorar las implicaciones del uso de estas primitivas
para la implementaci
´
on de los algoritmos de las pr
´
acticas
anteriores, a nivel de Aplicaci
´
on, de Biblioteca o de
Sistema Operativo, proporcionando una visi
´
on multinivel
coherente de un computador.
IV. ENT ORN O DE TRABAJ O
Esta secci
´
on describe los requisitos tanto hardware
como software que debe cumplir la plataforma com
´
un de
trabajo para el buen desempe
˜
no del proyecto presentado.
De hecho, puesto que resulta deseable que el uso de la
plataforma seleccionada se pueda extender a los cuatro
cursos del Grado mediante su uso en otras asignaturas y
proyectos relacionados, se estudian una serie de requisitos
y asignaturas que van m
´
as all
´
a de este proyecto. Una
vez presentados los requisitos y las asignaturas asociadas,
justificamos la elecci
´
on de la plataforma Raspberry Pi
como herramienta ´
unica de desarrollo.
A. Requisitos
A efectos de mejorar la legibilidad de la secci
´
on, la
Tabla I muestra el listado de asignaturas relacionadas
y sus correspondientes abreviaturas, incluyendo las
cuatro asignaturas que forman parte del proyecto
transversal, en negrita en la tabla. La Tabla II resume
los requisitos necesarios en una plataforma com
´
un de
TABLA I
ABREVIATURAS Y NOMBRE COMPLETO DE LAS ASIGNATURAS DEL
GRA DO REL ACIO NADAS C ON EL P ROYEC TO PRE SEN TAD O. EN
NE GRITA AQ UELL AS QUE F ORM AN PARTE D EL PROY ECTO
C´
odigo Nombre de asignatura
AA Aprendizaje Autom´
atico
AOC1, AOC2 Arquitectura y Organizaci´
on de Computadores 1 y 2
AS1, AS2 Administraci´
on de Sistemas 1 y 2
GyS Garant´
ıa y Seguridad
IA Inteligencia Artificial
IG Inform´
atica Gr´
afica
LabSE Laboratorio de Sistemas Empotrados
MP Multiprocesadores
PCD Programaci´
on de Sistemas Concurrentes y
Distribuidos
PCOM Procesadores Comerciales
PH Proyecto Hardware
RC Redes de Computadores
ROB Rob´
otica
SD Sistemas Distribuidos
SE1, SE2 Sistemas Empotrados 1 y 2
SO Sistemas Operativos
VID Videojuegos
VIS Visi´
on por computador
Fig. 5. Fotograf´
ıa de la plataforma seleccionada: Raspberry Pi.
trabajo, asignaturas asociadas y nivel de cumplimiento de
los mismos en distintas plataformas. Se han seleccionado
cuatro plataformas cuyo uso es ampliamente extendido:
Raspberry Pi [1], DragonBoard 410C [7], HiKey 960
5
, y
BeagleBoard X-15 [8].
B. Selecci´
on de Plataforma
A la vista de los resultados del estudio anterior,
numerosas asignaturas se podr
´
ıan beneficiar e integrar
en este proyecto u otros relacionados. Tanto Raspberry
Pi como BeagleBoard resultan buenas candidatas para su
uso en el Grado y permitir un aprendizaje transversal
utilizando conocimientos de m
´
ultiples asignaturas.
Sin embargo, de manera similar a otros trabajos
relacionados [2], [3], nos decantamos por Raspberry Pi
(v
´
ease Figura 5) principalmente por su bajo coste y la gran
aceptaci
´
on y cantidad de material adaptado disponible de
manera abierta y gratuita.
V. RE SULTAD OS ESPERADO S
Se espera que la utilizaci
´
on de un mismo hardware
permita relacionar los distintos niveles de abstracci
´
on en
los que las distintas asignaturas trabajan y as
´
ı unificar
5https://www.96boards.org/documentation/
consumer/hikey960/hardware-docs/
hardware-user- manual.md.html
TABLA II
TABLA DE REQUISITOS HARDWARE (H) Y SOFT WAR E (S), ASIG NATURA S DON DE ES R ELEVAN TE CAD A REQU ISI TO,Y SI L OS CUM PLE N O NO
LA S PLATAFO RMAS E STU DIAD AS: RA SPB ERRY PI(RP), DRAGONBOAR D 410C (DB), HIKEY 960 (HK) YBEAG LEBOA RD X-15 (BB)
Tipo Descripci´
on Asignaturas RP DB HK BB
H&S Multiprocesador
: muchos computadores actuales est
´
an basados en dise
˜
nos multiprocesador.
Los mecanismos software y hardware para ejecutar aplicaciones concurrentes y paralelas son
imprescindibles. Es necesario que la placa elegida incorpore varios procesadores.
AOC2, LabSE,
MP
,
PCD
, PCOM, ROB,
SD, SE1, SE2, VIS
X X X 7
HJTAG:
los ingenieros en inform
´
atica deben ser capaces de desarrollar aplicaciones a alto nivel
as
´
ı como interaccionar con el sistema a bajo nivel. El puerto JTAG es el interfaz est
´
andar para
realizar esta interacci
´
on y ofrece al programador la visibilidad de los elementos internos del
sistema (estado del procesador, contenido de los registros y memoria, etc).
AOC2, LabSE, PH,
SE1, SE2
7 7 7 X
HEthernet:
los computadores actuales realizan multitud de tareas v
´
ıa red, como conectarse a un
servicio o compartir informaci
´
on en sistemas distribuidos. El puerto Ethernet para conexi
´
on de
red v
´
ıa cable es muy deseable para poder probar por ejemplo conocimientos de redes y sistemas
distribuidos.
AS1, AS2, RC, SD X7 7 X
HWiFi:
entre las conexiones de red sin cables, la m
´
as frecuente es la WiFi, aunque hay otros
protocolos como Bluetooth o Zigbee que se emplean en dispositivos de muy bajo consumo y
peque˜
no alcance.
AS1, AS2, RC, SD X X X 7
HC´
amara:
una c
´
amara es un perif
´
erico muy
´
util para muchas asignaturas del Grado, no s
´
olo
VIS o IA, sino tambi
´
en otras como PH para mostrar c
´
omo gestionar un dispositivo que requiere
una baja latencia y un gran ancho de banda.
AOC1, IA, PH,
ROB, VIS
X X X 7
HSoporte virtualizaci´
on:
la virtualizaci
´
on es cada vez m
´
as frecuente en sistemas inform
´
aticos
para que un mismo hardware ejecute m
´
ultiples sistemas operativos y sus correspondientes
aplicaciones de manera concurrente. La virtualizaci
´
on puede tener mucha sobrecarga, pero
con un soporte hardware apropiado la sobrecarga se vuelve liviana. Con una peque
˜
na placa los
alumnos podr´
ıan simular la pila de sistema en nodos de un centro de datos.
AS2, GyS X X X 7
HExpansiones:
expansiones de placa como pantallas y/o pulsadores permiten experimentar con
la comunicaci
´
on existente entre el procesador del sistema y los perif
´
ericos. En PH uno de los
objetivos es desarrollar un sistema capaz de comunicarse directamente con los perif
´
ericos, por
tanto la placa debe incluir este tipo de elementos. Lo ideal ser
´
ıan dos pulsadores y una pantalla
(a poder ser t´
actil para facilitar la interacci´
on).
LabSE, PH X X X X
HGPUs:
las unidades de procesamiento gr
´
afico realizan en la actualidad dos tareas fundamentales:
renderizar y generar im
´
agenes para mostrar por pantalla y realizar operaciones de c
´
alculo
(permitiendo optimizaciones y paralelizaci
´
on mejorando el rendimiento de muchos algoritmos
respecto a su ejecuci´
on en CPU).
AA, IA,
IG
, LabSE,
MP
, PCOM, VID,
VIS
X X X X
HDSP:
un procesador digital de se
˜
nal est
´
a especializado en ejecutar algoritmos de procesado
de se
˜
nal. Se suelen emplear en sistemas de tiempo real tales como el m
´
odem de un tel
´
efono
m
´
ovil, debido a su potencia de c
´
alculo y bajo consumo, o como aceleradores de aplicaciones
espec´
ıficas, por ejemplo de visi´
on por computador.
LabSE, SE1, SE2,
VIS
7X X X
SEntorno de desarrollo:
el requisito principal es que debe permitir trabajar tanto a alto como
bajo nivel, con y sin SO. El lenguaje a utilizar en la mayor parte de las asignaturas ser
´
ıa C,
dado que se estudia en asignaturas de programaci
´
on y tambi
´
en es el m
´
as utilizado en entornos
de bajo nivel y SO. Tambi
´
en es necesario el soporte de otros lenguajes interpretados como
Python u otros ejecutados como C++ para cubrir buena parte de la titulaci´
on.
Todas X X X X
SProgramaci´
on para GPU:
aunque la placa disponga de GPU, si no dispone de las herramientas
software adecuadas (drivers, bibliotecas y runtimes) su uso estar
´
a muy limitado. Es interesante
que la GPU de la placa elegida soporte API de programaci
´
on tanto de la parte gr
´
afica (OpenGL,
OpenGL ES, Vulkan) como de la parte de computaci
´
on con APIs como OpenCL o Vulkan e
incluso CUDA.
IG
, LabSE,
MP
,
PCOM, VID
X X X 7
SProgramaci´
on del DSP:
al igual que en el requisito anterior, es necesario disponer de un buen
entorno de trabajo para aprender a manejar un DSP. Los DSPs suelen ser todav
´
ıa m
´
as complejos
que las GPUs, por lo que el soporte software es crucial para la elecci
´
on de placas que incluyan
un DSP.
LabSE, SE1, SE2,
VIS
7 7 7 X
SSoporte SO de alto nivel
: toda placa y/o sistema inform
´
atico se puede gestionar de dos modos:
con SO o sin
´
el (baremetal). El conocimiento integral de sistemas inform
´
aticos requiere que
los alumnos conozcan en profundidad ambas aproximaciones. En la mayor
´
ıa de asignaturas es
necesario un SO de alto nivel, como Microsoft Windows, Linux o Android.
AS1, AS2, SE1,
SE2, SO
X X X X
H&S Soporte sin SO (baremetal):
los SO proporcionan diversos servicios de gran utilidad pero
tambi
´
en consumen muchos recursos. Por ello, en sistemas peque
˜
nos es frecuente trabajar sin
ellos y es conveniente que el alumnado se familiarice con esta aproximaci
´
on. Es preciso que el
alumnado tenga muy claro el rol del SO y cuando se debe prescindir de ´
el.
AOC1, PH, SE1 X7X X
H&S Fiabilidad alta:
es necesario que la placa elegida tenga buen soporte y fiabilidad para no
retrasar el desarrollo de ninguna asignatura por motivos de errores ajenos/externos.
Todas X X X X
H&S Coste bajo:
para que se pueda conseguir f
´
acilmente que cada alumno trabaje con su propia
placa, se intentar´
a ajustar al m´
aximo el presupuesto requerido.
Todas X7 7 7
HBuena capacidad de envejecimiento:
medida en a
˜
nos en los que la placa tendr
´
a soporte por
parte del fabricante, ya que los alumnos deber
´
ıan poder emplear la misma placa varios a
˜
nos e
idealmente varias generaciones de graduados deber´
ıan poder utilizar la misma placa.
Todas X X X X
Tipo Descripci´
on Asignaturas RP DB HK BB
los problemas desde un enfoque global, lo cual supone
uno de los grandes retos de la titulaci
´
on. Permitir
´
a, por
tanto, ofrecer una formaci
´
on de mejor calidad y una mejor
concepci´
on del aprendizaje por parte del alumnado.
As
´
ı mismo, la propuesta del proyecto de innovaci
´
on,
que recoge este trabajo, ha supuesto la creaci
´
on de
un grupo de trabajo docente estable que facilitar
´
a la
comunicaci
´
on y las sinergias entre asignaturas. Las
din
´
amicas establecidas permitir
´
an incluir otras asignaturas
y otros casos de uso en el futuro.
El esperado uso com
´
un y progresivo de la plataforma
Raspberry Pi beneficiar
´
a a todo el alumnado que curse
Ingenier
´
ıa Inform
´
atica en UNIZAR, dado que se tiene
previsto utilizar esta plataforma en pr
´
acticas de asignaturas
troncales (adem
´
as de algunas optativas). En los
´
ultimos
cuatro cursos se han ofertado 123 plazas de nuevo ingreso
anualmente, 90 de ellas en el Campus R
´
ıo Ebro en
Zaragoza y el resto en el Campus de Teruel.
Se dispondr
´
a de los resultados completos de este
proyecto cuando hayan transcurrido cuatro cursos
acad
´
emicos desde su implantaci
´
on en el Grado. Al
finalizar estos cuatro cursos, el alumnado habr
´
a podido
completar el proyecto, siendo entonces cuando se
analizar´
an las competencias alcanzadas.
VI. CONCLUSIONES Y TRA BAJ O FUTU RO
Este art
´
ıculo ha presentado un proyecto transversal con
el objetivo de dotar al alumnado del Grado de Ingenier
´
ıa
Inform
´
atica de una visi
´
on de conjunto de los sistemas
inform
´
aticos, la cual tiende a diluirse con la estructura
actual del Grado en asignaturas aisladas.
El caso de uso presentado ha consistido en un
sistema inform
´
atico que implementa un trazador de
rayos paralelo con cuatro niveles de abstracci
´
on
introducidos en asignaturas distintas del Grado. El
desarrollo del mencionado sistema permite al alumnado
experimentar con las propiedades de la atomicidad,
consistencia, paralelismo y concurrencia a nivel de
Aplicaci
´
on, Biblioteca, Sistema Operativo y Lenguaje
M
´
aquina. El proyecto se sustenta con la elaboraci
´
on
de los correspondientes enunciados de pr
´
acticas para su
implementaci
´
on, as
´
ı como un estudio detallado de los
requisitos hardware y software para su desempe
˜
no y la
consecuente elecci
´
on de Raspberry Pi como plataforma
´
unica de desarrollo.
Durante el pr
´
oximo curso acad
´
emico 2018/2019 se
espera realizar un despliegue horizontal del proyecto
multinivel. De esta manera, estudiantes del
´
ultimo curso
del Grado que est
´
en interesados en testear la plataforma
podr
´
an implementar cada uno de los niveles de abstracci
´
on
y en su caso dar lugar a la realizaci
´
on de TFGs. Esta
tarea ser
´
a fundamental para recibir retroalimentaci
´
on y
refinar tanto el sistema propuesto como los enunciados de
pr
´
acticas de cara a una posible implantaci
´
on de las mismas
en el Grado para el curso 2019/2020. Adem
´
as, se plantear
´
a
la opci
´
on de a
˜
nadir m
´
as asignaturas como estad
´
ıstica para
realizar un an´
alisis m´
as detallado de los resultados.
AGRADECIMIENTOS
Este trabajo ha sido financiado por el Vicerrectorado
de Pol
´
ıtica Acad
´
emica de la Universidad de Zaragoza
mediante el Programa de Incentivaci
´
on de la Innovaci
´
on
Docente bajo las subvenciones PIIDUZ 17 365 y
PIIDUZ 16 270, por el Gobierno de Arag
´
on y el Fondo
Social Europeo (gaZ: T58 17R research group) y por
el Ministerio de Econom
´
ıa y Competitividad (MINECO)
bajo la subvenci
´
on TIN2016-76635-C2-1-R (AEI/FEDER,
EU).
REFERENCIAS
[1]
E. Upton and G. Halfacree, Raspberry Pi User Guide, John Wiley
& Sons Ltd., 2014.
[2]
C. Camarero, E. Z. Su
´
arez, E. Stafford, F. Vallejo, and C. Mart
´
ınez,
“Ense
˜
nanza Pr
´
actica de Estructura y Organizaci
´
on de Computadores
con Raspberry Pi,” in Actas de las XXVIII Jornadas de Paralelismo,
2017, pp. 305–312.
[3]
R. Asenjo, S. Gonz
´
alez, F. Corbera, A. Navarro, A. Rodr
´
ıguez,
J. Villalba, and E. M. T. Hendrix, “Motivando al alumno de
ingenier
´
ıa mediante la plataforma Raspberry Pi,” in Actas de las
XXVIII Jornadas de Paralelismo, 2017, pp. 313–320.
[4]
E. Veach, Robust Monte Carlo Methods for Light Transport
Simulation, Ph.D. thesis, Stanford, CA, USA, 1998.
[5]
U. Drepper, “Futexes Are Tricky,” 2011,
http://people.
redhat.com/drepper/futex.pdf.
[6] ARM, “ARM DS-5 Development Studio Examples,” 2018.
[7]
Qualcomm, DragonBoard
TM
410c based on Qualcomm
R
Snapdragon
TM
410E processor. Peripherals Programming Guide
Linux Android, Qualcomm Technologies, Inc., 2016.
[8]
G. Coley, BeagleBoard X15 System Reference Manual,
BeagleBoard.org, 2016.
