Los ingenieros de Google que contribuyen al kernel Linux han anunciado que han descubierto cientos de “race conditions” (condiciones de carrera) en el kernel usando KCSAN. La compañía ha estado trabajando durante mucho tiempo en AddressSanitizer para encontrar errores relacionados con la corrupción de la memoria o en UndefinedBehaviorSanitizer para un comportamiento indefinido en el código. Esta vez, Google ofrece un nuevo detector “Race Conditions” para el kernel Linux que se llama KCSAN (Kernel Concurrency Sanitizer).
Comentarios
que levante la mano quien no se haya enterado de nada, al menos por la entradilla. ☝
#1: Dicen que han encontrado algo de carrera, lo que no dicen es el curso y si es troncal, obligatoria o optativa. #troll
#5 Hablan de si el tifón molestará a la carrera en suzuka
#1 una condicion de carrera se produce cuando distintos hilos de ejecución acceden a la misma variable para para escribir su valor. Como el hilo que se ejecutará depende de un conjunto de condiciones, tanto hardware como software, no se puede predecir el orden en que esos hilos van a modificar el valor de la variable, por lo que el resultado de la operación es indeterminado. Como dice #3, arreglar estos fallos es jodido porque son muy dificiles de reproducir por lo que tener una herramienta que te dé un listado de ellos es un gran avance.
#6 gracias. En la noticia desarrollada lo entendí. Para un medio genérico, como es Menéame, creo que la entradilla debería ser un poco más explicativa, y no los primeros párrafos, aunque posiblemente está bien para una web tecnológica.
#1
La condición de carrera se produce cuando hay varios hilos (threads) que modifican (o leen) una misma posición de memoria sin respetar el orden de programa.
Es decir, puede que un hilo escriba en una posición de memoria antes de que otro hilo la haya leído. Cuando ese otro vaya a leerla obtendrá un valor erróneo. La dependencia también se puede dar al revés: que un hilo que tenga que esperar a que otro escriba se adelante y lea un valor sin actualizar.
En este artículo hablan de condiciones de carrera. Otro problema que se da en la programación multihilo es el de los abrazos mortales (deadlocks). Estos ocurren cuando los hilos no pueden avanzar debido a una mala gestión de la protección que evita las condiciones de carrera. El bloqueo se da cuando un hilo no puede obtener acceso un recurso porque hay otro que no lo permite. Para evitar el abrazo mortal basta con que cualquiera de las 5 condiciones siguientes se cumpla:
* Todos los hilos adquieren los recursos en el mismo orden (evita esperas circulares: H1 espera a H2, H2 a H3, H3 a H4 y H4 a H1).
* Cuando un hilo coge un recurso no esperar a que otro hilo libere otro. Evita la inanición.
* No utilizar exclusión mútua. Esto nos lleva a los spinlocks de Linux y la aparición de las condiciones de carrera.
* No quitarle el recurso a un hilo que ha obtenido acceso al mismo.
* No me acuerdo.
Otro es el livelock. Se da cuando dos hilos bloquean y desbloquean un recurso pero no hay avance en el programa. Esto se puede dar cuando dos procesos tratan de obtener un recurso al mismo tiempo y como ambos detectan que otro está cogiéndolo lo liberan y vuelven a tratar de obtener el recurso.
https://es.wikipedia.org/wiki/Abrazo_mortal
#8: Gracias, por un momento creía que hablaban de medias (para las piernas) y de lo que pasaba cuando un hilo se rompía.
Pues con lo infernal que es reproducir bugs causados por condiciones de carrera, enhorabuena al equipo de KCSAN. Ahora solo falta que tambien pongan a ingenieros a arreglarlos
#3 Llevan unos cuantos arreglados ya, si ves el repositorio hay una lista: https://github.com/google/ktsan/wiki/KCSAN#upstream-fixes-of-data-races-found-by-kcsan
De momento van 3 de RCU que son locks, de modo que afectarían a la práctica totalidad de subsistemas del kernel.
Las condiciones de carrera no son moco de pavo. 3 personas murieron por culpa de un bug de ese tipo en una maquina de radioterapia: https://es.wikipedia.org/wiki/Therac-25
Una noticia estupenda, seguro que esto soluciona algún cuelgue o bug "inexplicable" y no reproducible de una máquina linux
Que no lo prueben con Nodejs o les llena el cloud entero con los logs