Implementaci´ on

La implementaci´on del algoritmo de generaci´on de invariantes lineales fue rea- lizada como parte del trabajo de tesis final de la Lic. Natalia Beatriz Bi- dart [Bid07]. Este desarrollo fue incluido en el prototipo de software que descri- biremos en el cap´ıtulo5.

El algoritmo fue escrito en el lenguaje ML, en su implementaci´onStandard ML of New Jersey [Sta06], utilizando la biblioteca externa NewPolka [Jea05] para la manipulaci´on de poliedros.

Cap´ıtulo 4

Implementaci´on de regiones

cr´ıticas condicionales

En cap´ıtulos anteriores desarrollamos una formalizaci´on de los sistemas de tran- siciones junto con diferentes t´ecnicas para comprobar propiedades sobre los mis- mos. La principal motivaci´on de este trabajo es la aplicaci´on de estas t´ecnicas para la optimizaci´on de construcciones concurrentes utilizadas en los lenguajes de programaci´on. Se entiende a estas construcciones como estructuras sint´acti- cas de alto nivel que permiten una abstracci´on del hardware o de primitivas del lenguaje para resolver de forma simple problemas de concurrencia, como por ejemplo regiones cr´ıticas condicionales y monitores. Por lo general, debido al alto nivel de estas construcciones, su implementaci´on autom´atica por medio de compiladores o generadores de c´odigo suele ser poco eficiente.

En este mismo sentido, la t´ecnica de sem´aforos binarios divididos [Dij79] puede ser usada para implementar regiones cr´ıticas condicionales. Dada una es- pecificaci´on de un problema de esta clase, SBD brinda tanto los programas que lo implementan como los invariantes que aseguran su correcci´on. Aplicando la t´ecnica a casos particulares se encuentran programas que admiten ciertas sim- plificaciones que mejoran la eficiencia. Este trabajo se concentra en el desarrollo de procedimientos autom´aticos para obtenerlas. Nos enfocamos particularmente en la eliminaci´on de guardas en las sentencias condicionales finales de los progra- mas, pero el m´etodo permite su generalizaci´on a otros tipos de simplificaciones. El procedimiento consiste en representar de manera abstracta una implemen- taci´on SBD de regiones cr´ıticas condicionales por medio de sistemas de tran- siciones (cap´ıtulo 1) y hacer una b´usqueda de nuevos invariantes (cap´ıtulo 2) que avalen la correcci´on de las simplificaciones. La t´ecnica principalmente utili- zada para ello espropagaci´on hacia atr´as (secci´on2.3.2, p´ag.53). Como vimos, este m´etodo permite constatar la invariancia de predicados sobre los sistemas de transiciones y posee la ventaja de que la cadena tendiente al punto fijo es usualmente finita.

Una ventaja adicional que posee la t´ecnica de propagaci´on hacia atr´as es que los predicados intermedios son f´ormulas libres de cuantificadores como se mencion´o en el cap´ıtulo2. De esta manera, la obtenci´on de los mismos puede hacerse de forma mec´anica con la ayuda de chequeadores de validez de f´ormulas de primer orden con teor´ıas subyacentes denominados SMT solvers, como por

104 CAP´ITULO 4. REGIONES CR´ITICAS CONDICIONALES ejemplo CVC3 [BT07,CVC08] y Yices [yic08].

Desafortunadamente las f´ormulas producidas en el proceso de c´alculo de punto fijo son generalmente grandes ya que en cada paso del c´alculo iterati- vo se produce un incremento en el tama˜no de las mismas. Con el fin de ali- viar este fen´omeno, se desarrollaron m´etodos de simplificaci´on de las f´ormu- las intermedias, implementados con los probadores de teoremas CVC3 e Isabe- lle/HOL [Pau94].

En la actualidad las herramientas denominadas en forma gen´erica “proba- dores de teoremas” han demostrado una gran madurez, siendo utilizadas de manera exitosa en la verificaci´on de software. Nuestro trabajo tiene un objetivo diferente: pretende atacar el problema de eficiencia antes mencionado utilizando estas herramientas.

La propuesta de este trabajo fue implementada en un prototipo de software escrito en el lenguaje de programaci´on ML utilizando demostradores de teoremas externos para probar las implicaciones envueltas en el c´alculo de punto fijo y simplificar f´ormulas l´ogicas. El procedimiento fue probado sobre diferentes ejemplos cl´asicos de programaci´on concurrente.

La t´ecnica propuesta es incompleta ya que puede no detectar guardas cuya eliminaci´on es correcta. Sin embargo en la mayor´ıa de los ejemplos de la litera- tura se detectaron todas las simplificaciones posibles. Cabe remarcar que esta incompletitud no es un problema a la hora de obtener programas correctos: las implementaciones de regiones cr´ıticas condicionales producidas por la t´ecnica SBD sin estas simplificaciones son correctas aunque menos eficientes. En este sentido, el objetivo de aplicaci´on del m´etodo autom´atico propuesto se dirige a implementaciones de compiladores o generadores de c´odigo para aumentar la eficiencia de construcciones concurrentes de alto nivel.

El trabajo ha sido presentado en [BB07a,BB07b]. Aqu´ı profundizaremos es- tas publicaciones en detalle. En las secciones4.1,4.2y4.3se plantea el problema con sus antecedentes. En las secciones 4.4, 4.5, 4.6 y 4.7 se presenta el m´eto- do propuesto con su implementaci´on. Por ´ultimo en las secciones 4.8 y 4.9 se muestran los resultados con sus conclusiones y los trabajos futuros propuestos.

4.1

Regiones cr´ıticas condicionales

Una gran cantidad de problemas concurrentes pueden ser resueltos usando los conceptos de espera condicional y exclusi´on mutua. Por ejemplo en [And89] se presenta un m´etodo relativamente general para resolver problemas de sincro- nizaci´on usando espera condicional xawait.B ÞÑ Sy el cual sirve para resolver ambos problemas iniciales (espera condicional y exclusi´on mutua). De manera general, las esperas condicionales funcionan bloqueando el proceso que ejecuta el programa hasta que la condici´onBsea verdadera y en este caso el programaS se ejecuta en exclusi´on mutua.

Las construcciones de espera pueden aparecer en cualquier punto de los pro- gramas causando que las variables en la condicionesBy en los programasSsean compartidas por los distintos procesos que las ejecutan. Esta libertad del con- texto en donde aparecen las variables produce algunas dificultades al momento de implementarlas. La forma cl´asica para implementar esta construcci´on es a trav´es de buclesbusy waiten cada guarda de las distintas esperas condicionales. El principal problema reside en que se deben chequear todas las guardas que

4.1. REGIONES CR´ITICAS CONDICIONALES 105 aparecen en las distintas esperas de los procesos. Adem´as, cuando se realiza esta comprobaci´on, se deben bloquear todos los procesos que usen las varia- bles de las guardas para que no interfieran en el resultado de esta evaluaci´on. Es importante agregar que en muchos contextos de ejecuci´on concurrente, es com´un que existan guardas que no sea necesario evaluar, dejando como tarea al programador la eliminaci´on de las mismas para una mejora en la eficiencia del sistema.

A partir de esta dificultad en la implementaci´on de las esperas condiciona- les, diversas construcciones m´as simples de sincronizaci´on han sido propuestas (como por ejemplo sem´aforos). Estos mecanismos son menos abstractos que la espera condicional y pueden usarse para implementar esta construcci´on. Esta perdida de abstracci´on introduce nuevas necesidades de prueba en el proceso de desarrollo de los programas, incrementando su complejidad y por consiguiente generando nuevas posibilidades de cometer errores. La presencia de errores su- tiles, tanto de correcci´on (safety) como de progreso (en particular la posibilidad de deadlocks o livelocks) ha sido desafortunadamente m´as la regla que la excep- ci´on. Toda propuesta de nuevas herramientas de sincronizaci´on ha sido siempre una soluci´on de compromiso entre facilidad de uso y posibilidad de reducir las penalidades en eficiencia.

En este sentido, las regiones cr´ıticas condicionales fueron propuestas por C.A.R. Hoare [Hoa72] y Brinch Hansen [Han72] como una construcci´on m´as cercana a la espera condicional y por lo tanto m´as f´acil de usar correctamente. Las mismas se presentan con una notaci´on estructurada para especificar sin- cronizaci´on, donde se hace necesario declarar expl´ıcitamente las variables com- partidas sobre las cuales se operar´a en exclusi´on mutua y que podr´an aparecer en las condiciones. La construcci´on de alto nivel para denotar regiones cr´ıticas condicionales requiere que cualquier variable compartidavsea declarada como:

resource rccpvq

De esta manera se obliga a que la variablevpueda ser usada solo dentro de una regi´on declarada como:

region rcc BÞÑSend

Esta construcci´on significa que mientras el programa S esta siendo ejecutado, ning´un proceso puede acceder a la variablevy que la guardaBgobierna el acceso a esta regi´on cr´ıtica. Adem´as la ejecuci´on de S debe realizarse en exclusi´on mutua.

Una manera de implementar regiones cr´ıticas condicionales con construccio- nes m´as simples fue propuesta por E.Dijkstra [Dij79] retomando ideas previas de C.A.R. Hoare [Hoa74]. La t´ecnica fue denominadasem´aforos binarios dividi- dos (SBD) y utiliza una serie de sem´aforos binarios para asegurar la exclusi´on mutua entre las regiones. Esta metodolog´ıa brinda tanto los programas (con sem´aforos binarios) que implementan las regiones cr´ıticas condicionales como los invariantes iniciales que aseguran su correcci´on.

Debido a la generalidad de la metodolog´ıa, los programas resultantes suelen ser poco eficientes; como veremos, en estos programas aparecen guardas en sen- tencias condicionales que son falsas en cualquier contexto de ejecuci´on posible. Es por esto que, para mejorar la eficiencia, la t´ecnica incluye la eliminaci´on,

106 CAP´ITULO 4. REGIONES CR´ITICAS CONDICIONALES mediante demostraciones de correcci´on en forma manual, de estos chequeos in- necesarios en los puntos en los cuales puede deducirse formalmente que una condici´on ser´a falsa. Dado que las secciones cr´ıticas suelen ser peque˜nas pe- ro son invocadas numerosas veces, estos peque˜nos ahorros pueden representar incrementos dr´asticos en la eficiencia de los programas.

El desarrollo en los ´ultimos a˜nos de los demostradores (semi)autom´aticos de teoremas brinda un nuevo contexto sobre el cual una parte interesante de estas simplificaciones puede hacerse de manera mec´anica, abriendo la posibilidad de reducir significativamente las penalidades en eficiencia en las de construcciones de alto nivel para la construcci´on de programas concurrentes. Esta nueva alter- nativa resulta totalmente relevante en el contexto actual ya que la necesidad de crear programas con estas caracter´ısticas no es nueva aunque ha tomado parti- cular inter´es en los ´ultimos tiempos. La popularidad de arquitecturas paralelas, con el advenimiento de los procesadores multicore, ha renovado la necesidad de elaboraci´on de t´ecnicas y construcciones concurrentes para aprovechar la caracter´ısticas de estas arquitecturas. El problema surge debido a que actual- mente estas metodolog´ıas est´an lejos de cumplir el desaf´ıo. Conocidas cat´astrofes econ´omicas fueron producidas por errores en programas concurrentes [Gib94]. Problemas al intentar aprovechar estas arquitecturas para la actualizaci´on del sistemas operativos SunOS est´an descriptos en [Cre05]. Son tambi´en destacables casos como el desarrollo del kernel de Ptolemy II [EJL 02] donde se descubrieron errores mucho tiempo despu´es al probarlos en estas arquitecturas, a´un cuando el desarrollo estuvo altamente testeado [Lee06].

Uno de los problemas centrales de las ciencias de la computaci´on es la de pro- veer construcciones concurrentes de alto nivel sin penalidades en la eficiencia. Al momento de atacar este problema, las construcciones concurrentes de alto nivel propuestas, como regiones cr´ıticas condicionales y monitores con se˜nalamiento impl´ıcito, no han tenido buena aceptaci´on debido a sus problemas de eficiencia. La madurez que en la actualidad han obtenido los probadores de teoremas los hace una herramienta interesante a la hora de resolver estas cuestiones. Nuestro trabajo intenta mostrar esta posibilidad tomando una construcci´on de alto ni- vel (regiones cr´ıticas condicionales) y mejor´andola incrementando su eficiencia gracias al uso de este tipo de herramientas.

A continuaci´on explicaremos la t´ecnica SBD junto con un ejemplo de simpli- ficaci´on del programa resultante hecho en forma manual con el fin de visualizar el problema que se intenta resolver.