Pregunta

Recientemente, me encontré teniendo que escribir algunas inquietudes que tengo sobre las condiciones de carrera en una aplicación que está en desarrollo (no para mí). Es probable que esto se señale a las partes interesadas que no son técnicas y con las que no tengo una línea de comunicación directa, por lo que mi explicación debe estar en forma escrita.

Ya he intentado este artículo. Analizo las especificaciones técnicas lo mejor que puedo, doy un ejemplo de cómo ocurriría una condición de carrera en la aplicación y describo su impacto. Siento que lo hice bastante bien, pero está lejos de ser perfecto.

El problema es que, por mucho que trato de proteger al lector de la informática, todavía me resulta difícil eliminar frases como "hilos de ejecución". y "exclusión mutua" sin perder la corrección y la sustancia. El riesgo es que, con demasiados movimientos de mano, estas preocupaciones podrían ser descartadas como un hombre del saco inventado.

De todos modos, mi pregunta es la siguiente: ¿Cómo usted explicaría las condiciones de carrera a un público no técnico? ¿Te atreverías a explicar la programación de la CPU? ¿Invocarías a los filósofos gastronómicos ?

No tiene que trabajar dentro de las limitaciones de mi situación (pero sería increíblemente útil si lo hiciera).

¿Fue útil?

Solución

La empresa X tiene $ 1,000 en el banco. X paga un alquiler de $ 2,000 y recibió un pago de $ 10,000 por los servicios prestados a la compañía Y. Sin embargo, debido a una condición de carrera, X tiene un déficit de $ 1,000 y ahora está solicitando bancarrota. = (

Es posible que desee explicar cómo maneja el banco la cuenta de la empresa X de esta manera: el personal del banco A toma el valor actual de $ 1,000 y le agrega $ 10,000. El personal del banco B toma el valor actual de $ 1,000 y le resta $ 2,000. El personal del banco A actualiza el valor a $ 11,000. El personal del banco B actualiza el valor a - $ 1,000.

Otros consejos

Creo que las transacciones bancarias podrían ser un buen ejemplo, tanto porque es fácil ver que un resultado incorrecto es malo como porque las condiciones de carrera son fáciles de crear en ese entorno.

Tengo $ 500 en mi cuenta. Alguien me transfiere $ 200 al mismo tiempo que retiro $ 50.

Ahora, si el banco no maneja las condiciones de la carrera correctamente, hará lo siguiente (suponiendo que las transacciones se manejen manualmente, por supuesto) El secretario A verá la solicitud de agregar $ 200 a mi saldo, y tenga en cuenta que mi saldo es actualmente de $ 500. El secretario B verá la solicitud para restar $ 50 de mi saldo, y tenga en cuenta que mi saldo actualmente es de $ 500 (el secretario A aún no ha transferido el dinero).

El secretario A finaliza el papeleo y establece el saldo de mi cuenta en $ 700 (500 + 200 que se suponía que debía agregar). Y luego, un minuto después (porque el empleado B solo tenía que tomar una taza de café), el empleado B termina la otra transacción y establece mi saldo en $ 450 (los 500 que tenía cuando revisó, menos los 50 que estaba destinado a restar) ).

Mi saldo ahora es de $ 450, cuando debería haber sido de $ 650, debido a una condición de carrera. El resultado dependía del orden en que se realizaban las diferentes partes de las dos transacciones.

Esa es la descripción general de cómo las condiciones de carrera son malas. Ahora digamos que en lugar de empleados, tenemos nuestra aplicación procesando dos tareas separadas al mismo tiempo (esos son sus 'hilos de ejecución'), y al igual que arriba, ambos leen un valor, modifican el valor que ellos leer y luego volver a escribirlo. Una de las modificaciones puede perderse si esto sucede en el orden que se muestra arriba. Eso debería relacionarlo con los problemas específicos de su aplicación.

Iría por un enfoque al estilo de un filósofo gastronómico, pero dependiendo de mi audiencia, trataría de analogizarlo con el contexto de mi audiencia. ¿Estás hablando con ejecutivos de negocios? Luego, analícelo con algo como asignar una sala de reuniones o un automóvil corporativo o reservar una habitación de hotel o lo que sea. ¿Estás hablando con la gente promedio? Entonces el ejemplo del filósofo gastronómico está bien, o puede pensar una situación similar que implica cuidar animales de granja o sentarse en sillas o lo que sea.

Si secuestra el ejemplo del filósofo gastronómico o inventa el suyo, definitivamente use una metáfora.

Si está escribiendo a una audiencia no técnica, querrá simplificar sus explicaciones y relacionarlas con algo que puedan entender. Una explicación tomada del documento Analogías para enseñar computación paralela a programadores sin experiencia ( http: // portal .acm.org / citation.cfm? doid = 1189136.1189172 ) lo explica en términos de un juego de bolígrafos:

  

Vamos a jugar un juego llamado   Pen Game. Las reglas son simples: soy   va a sostener un bolígrafo en mi mano, y   entonces diré "Uno, dos, tres, vete".   Cuando digo "vete", toma el bolígrafo de mi   mano. Quien consiga la pluma gana.   Listo? Uno, dos, tres, vamos.

Luego preguntas si el resultado de este juego se puede predecir de antemano. Si no se puede predecir, ¿podemos garantizar un resultado correcto? Esto debería llevar a la comprensión de que es posible obtener resultados incorrectos para las escrituras simultáneas en la misma pieza de memoria.

Iba a recomendar a los filósofos gastronómicos, pero veo que ya lo has encontrado. Entonces, como alternativa, ¿qué tal si utilizamos el bloqueo como analogía?

Imagine el tráfico normal conduciendo por las cuatro calles al lado de una sola cuadra de la ciudad (North Ave, South Ave, East Street y West Street). Cuando solo hay uno o dos autos en la carretera, todo se mueve sin problemas. Cuando hay tráfico constante, algunos autos tendrán que detenerse y esperar a que pasen otros, pero este es un problema manejable. Un automóvil se detiene para esperar a que pase otro automóvil, y luego continúa alegremente.

Ahora, visualice el tráfico de la hora pico en el mismo lugar. Digamos que un automóvil que conduce hacia el sur en la calle West no puede atravesar la intersección en la esquina noroeste de nuestra manzana. Ese auto ahora bloquea todo el tráfico cruzado en dirección oeste en North ave. No pasa mucho tiempo antes de que un automóvil hacia el oeste intente atravesar la intersección de la esquina noreste y se quede atascado, bloqueando todo el tráfico hacia el norte en la calle Este. Cuando esta situación da la vuelta a las cuatro intersecciones, ¡ningún automóvil puede moverse! Cada uno está esperando que los autos delante de él avancen, pero no hay forma de que se libere el embotellamiento sin tirar de los autos hacia atrás.

La comparación con la informática debe ser sencilla. Los automóviles son hilos o procesos, las calles y avenidas son procesadores, amortiguadores o núcleos. El concepto de bloqueo se puede describir usando semáforos o señales de alto, y todo comienza a tener sentido intuitivo, incluso para los no programadores.

Escribir un programa:

  1. Espere el salario.
  2. Ir a la tienda.
  3. Compre comida.
  4. Encienda el plato.
  5. Poner comida en el plato.
  6. Mantenga el plato durante 20 minutos.
  7. Come.
  8. Ve a la cama.

Ahora intenta que dos hilos (tú, esposa) lo ejecuten sin sincronización.

  • Usted: espere el salario.
  • Esposa: Ve a la tienda sin dinero, choca

  • Usted: Encienda el plato.

  • Usted: Guarde el plato por 20 minutos.
  • Tú: Vete a la cama.

  • Esposa: comer en casa de otra persona.

  • Esposa: Vete a la cama.

Peter quiere salir de su camino de entrada. Comprueba que no hay nada en el camino de su automóvil, luego entra. Su hijo Frank se esconde detrás del automóvil. Peter no puede verlo y lo atropella.

Lo importante aquí es que para una computadora, "inspeccionar" y "modificar" tienden a ser dos acciones separadas, por lo que un ejemplo en el que no puede verificar algo cuando lo modifica es bueno.

¿Qué tal lo obvio?

Una condición de carrera es literalmente una carrera entre dos personas.

Una empresa está haciendo una oferta en un proyecto. Dos empleados que trabajan de forma independiente en las ofertas las presentan al cliente, pero uno de los empleados tiene información desactualizada. Ninguno de los empleados sabe que el otro está en proceso de presentar una oferta, por lo tanto, dependiendo de quién sea más rápido, la primera oferta puede ser reemplazada por el empleado más lento. Esto causará confusión ya que la oferta puede haber cambiado con el tiempo.

Es necesario que haya comunicación entre los dos empleados para trabajar juntos o detener a uno de ellos.

Una dificultad para explicar el concepto general es que las condiciones de carrera se manifiestan en una amplia variedad de situaciones. Si su objetivo es dar a su audiencia no técnica la sensación de que se trata de un tipo de problema genérico, debe intentar ofrecer más de un ejemplo.

Una imagen vale más que 1000 palabras. Es verdad. Si dibuja una línea de tiempo y coloca alguna entidad en ella, y muestra sus cambios de estado a medida que pasa el tiempo, puede demostrar una condición de carrera con bastante facilidad en un diagrama. Puede tomar algunos rehacer para obtener la imagen correcta, pero siempre he descubierto que dibujarla hace que mi punto de vista sea más rápido que describirlo.

Creo que es difícil explicar esto de una manera simple, porque pensar en la concurrencia es inherentemente difícil. La idea básica de una transacción financiera podría ser un buen lugar para comenzar, ya que las personas estarán familiarizadas con ellos en la vida real.

En cualquier tipo de transacción, debe realizar entradas simultáneas en dos lugares: débitos y créditos. Si la transacción se interrumpe en el medio por otra persona que intenta realizar otra transacción, verá el saldo incorrecto en una u otra cuenta.

Hay un gran ejemplo en Programación concurrente estructurada con aplicaciones de sistemas operativos ( como recuerdo)

En el país empobrecido de Bezerkistan, dos líneas se unen en una sola pista en un túnel. Ha habido colisiones y la junta gobernante necesita una solución.

El problema es que es montañoso y los ingenieros son ciegos. Hay muy poca advertencia previa de dos trenes a punto de chocar en el túnel.

Aquí está el plan.

  1. Coloque un tazón grande en la unión.

  2. Dele a cada ingeniero un pequeño mono de latón.

Cuando estás a punto de entrar al túnel, detienes tu tren. Usted da vueltas en el tazón para ver si hay un mono de latón en el tazón.

Si hay un mono, alguien más está usando el túnel, por lo que debe esperar hasta que su tren esté completamente en el túnel, momento en el cual el conductor sale del furgón de cola y toma al mono del tazón.

Si no hay mono, nadie más está usando el túnel. Entonces, puedes agarrar a tu mono del compartimiento del motor, ponerlo en el tazón y conducir por el túnel, sabiendo que has obtenido acceso exclusivo a la pista. Por supuesto, se detiene brevemente para permitir que el conductor recupere el mono de bronce.

¿Adivina qué?

¡Ellos todavía tenían colisiones!

¿Por qué? ¿Cuál es la situación o secuencia de acciones que hace que esto falle?


Esa es una condición de carrera.

En un documento escrito, puede explicar cómo la condición de la carrera conduce a un accidente.

En una presentación, puede entrenar a la audiencia a través del razonamiento sobre concurrencia y bloqueo.

usaría un ejemplo de cuenta bancaria de memoria compartida de una condición de carrera de datos.

explique que la computadora hace algo como: equilibrio de carga; agregar 1; saldo de la tienda ;. considere dos hilos que están modificando el saldo de su cuenta bancaria (usted y su esposa están depositando un dólar al mismo tiempo).

si ambos hilos se interrumpen después del: balance de carga; y luego reanudar, puede perder un dólar.

ver: http://wasp.cs.washington.edu/atomeclipse/handouts .pdf

Como mencionó, a menudo necesita introducir otros conceptos (exclusión mutua, hilos de ejecución) para describir con precisión las condiciones de carrera, incluso en una metáfora. Intente definir estos términos (o al menos transmitir la idea) primero, usando la metáfora.

Como un ejemplo simple, usemos una intersección de 4 vías (en un país donde conduzca a la derecha). Divida la intersección en 4 cuadrantes: Noroeste, Nordeste, Sudeste y Sudoeste. Ahora llame a cada cuadrante un recurso, y llame a cada automóvil un hilo de ejecución. Estos autos solo respetan los sistemas de tránsito, y dado que no hay señales de alto o semáforos en esta intersección, los autos avanzan sin detenerse ni considerar el tránsito.

Puede mostrar fácilmente que el uso simultáneo de uno de estos cuadrantes por parte de más de un automóvil es malo y da lugar a un accidente automovilístico. Una solución obvia es instalar un sistema de tráfico. El sistema asegura que no más de un automóvil pase por un cuadrante al mismo tiempo. Puede hacer esto intrincadamente, sin atar todos los recursos. Por ejemplo, dejar que los autos que vienen del sur giren a la izquierda para dirigirse al oeste (usando los cuadrantes sureste y noroeste), mientras que los autos que vienen del oeste giren a la derecha para ir al sur (usando el cuadrante sur-oeste) . El sistema de tráfico proporciona exclusión mutua o impide el uso simultáneo (por varios automóviles) de un recurso común (el cuadrante de la carretera en la intersección).

Esto al menos proporciona las ideas detrás de estas definiciones, la idea de que acceder simultáneamente a los recursos compartidos puede ser malo y que la exclusión mutua puede resolver este problema. Una vez establecido esto, deberá asignarlos a una metáfora más apropiada para mostrar qué es una condición de carrera y cómo es una de esas cosas malas que resulta de la falta de exclusión mutua de un recurso común.

Lleva un poco más de tiempo, pero otorga cierta familiaridad con los términos y el panorama general antes de profundizar en una metáfora más compleja.

Hablar sobre el dinero con sus partes interesadas podría enviarlos al modo de pánico, especialmente si asumen que están perdiendo dinero real debido a esto, lo cual no es exactamente ideal si el problema no resulta específicamente en una pérdida neta de ganancias, así que aquí hay un historia menos orientada financieramente sobre cómo explicar una condición de carrera a cualquiera.

Esta historia no aborda el concepto de punto muerto , sino el escenario y las consecuencias más tradicionales de la condición de carrera.

LA HISTORIA COMIENZA AQUÍ:

La configuración: hay 3 ciudades conectadas por una red ferroviaria. Los trenes no tienen ningún letrero que indique de qué ciudad provienen y a qué ciudad irán porque están siendo utilizados entre las 3 ciudades y la red ferroviaria no quería lidiar con la molestia de cambiar todos los letreros. hora. Como la red es pequeña, no hay un horario concreto sobre cuándo llegan y salen los trenes. Los supervisores de la estación solo reciben una llamada de los demás supervisores de la estación de la ciudad cuando sale un tren, el supervisor toma nota de la hora en que se fue y, dado que todos los trenes son del mismo modelo, conducen a la misma velocidad, por lo que cuando el supervisor recibe una llamada de las otras ciudades anuncian a las personas en la estación que: "El próximo tren se dirigirá a la ciudad C". Entonces, las personas que desean viajar a la ciudad C esperan el tren, se suben y viajan alegremente a la ciudad C.

El problema: Pero un día, cuando un tren estaba planeando su ruta de A a B a C, se descompuso a mitad de camino entre A y B. Por suerte, los técnicos son muy hábiles y lo harían poder reparar el tren en poco tiempo. Sin embargo, ese mismo día, otro tren también estaba planeando una ruta diferente de C a B a A. El supervisor de la estación B recibió una llamada de A de que venía un tren, y poco después recibió otra llamada de C de que otro tren también venía. El supervisor de la estación luego anunció a los pasajeros que esperaban en la estación: "El primer tren que llegue se dirigirá a la estación C, y poco después el tren se dirigirá a la estación A." A medida que los pasajeros recogieron su equipaje y fueron a sus respectivas plataformas. El supervisor vio venir un tren y redirigió los rieles a la plataforma donde la gente planeaba dirigirse a la ciudad C. Poco sabían que el tren iba a la ciudad A en su lugar. El otro tren, después de haber solucionado sus problemas mecánicos, también llegó a la estación y el supervisor felizmente lo dirigió a la plataforma que contenía pasajeros que deseaban ir a la ciudad A. No hace falta decir que ninguno de los pasajeros llegó a donde planearon, todo porque el el supervisor supuso que llegarían en orden como de costumbre.

El problema con las condiciones de carrera y muchos conceptos informáticos es que las personas no son computadoras. Cada vez que explico un algoritmo a mis alumnos, dicen "pero no tiene sentido hacerlo de esa manera", a lo que respondo que "las computadoras no tienen sentido común, todo lo que tienen son instrucciones". Aparte de eso, debes explicar una condición de carrera como una carrera, y tiene más sentido dejar que las personas realmente prueben la carrera, si pueden. De esa manera pueden ver cómo van las cosas mal. Pero ... no se les permite usar el sentido común.

Entonces, supongamos que tenemos un juego en el que 2 personas llenan pilas de bloques de colores en orden Rojo, Naranja, Amarillo. Tienen muchos bloques rojos, naranjas y amarillos. Todas las pilas deben tener exactamente tres bloques de altura.

En el primer juego, ambos intentan hacer esto lo más rápido posible, pero solo trabajan en sus propias pilas.

En el segundo juego intentan trabajar juntos permitiéndose también apilar bloques en las pilas de los demás. Sin embargo, no se les permite cambiar el bloque que tienen en su mano, y tienen que colocar un bloque planificado.

Puedes imaginar una situación como esta en la pila 1:

player 1 grabs a red block
player 1 places red block         - player 2 grabs an orange block
player 1 grabs an orange block    - player 2 places an orange block
player 1 places an orange block

Entonces ahora tenemos una pila con dos bloques naranjas. Es obvio que con un juego humano esto nunca sucedería, porque las personas tienen sentido común: ven que el bloque naranja ya está colocado y revierten su decisión de colocar también un bloque naranja.

También puedes mostrarles este video: https://www.youtube.com/watch? v = TcGwNdbsAbc

Usemos una pizarra para hacer una tarea trivial de contabilidad. Tenemos $ 100 a mano, escríbalo en la pizarra.

Alice tiene docenas de facturas que suman $ 100, por lo que va a notar que $ 100, vaya y sume su lista y regrese en 5 minutos y escriba $ 200 en la pizarra.

Bob ha estado de compras. Él va a tomar ese número de la pizarra e ir a restar $ 50 en compras, y luego va a escribir $ 50 en la pizarra.

Si Bob regresa primero, veremos $ 200 después de que Alice escriba su resultado. Si Alice regresa primero, veremos $ 50, también mal. Lo que queremos ver es $ 150, y necesitamos agregar algunas precauciones en algún lugar para que eso suceda.

Eso debería ser suficiente para organizar una discusión sobre soluciones técnicas con intuiciones razonables.

Por ejemplo, un mutex significa que cierra la puerta de la habitación con la pizarra y hace que hagan su trabajo allí. Una solución optimista significa que puede hacer que ambos verifiquen y comiencen de nuevo si el número cambió mientras estaban fuera. Si quieres hablar sobre puntos muertos, puedes reírte de que Bob llame a Alice desde el interior de la habitación cerrada para pedirle que se apure.

Envíelos a Condición de carrera en Wikipedia.

La primera parte tendrá algún sentido, y el resto (no se muestra a continuación) te hará ver inteligente, ya que asumirán que lo entiendes.

" Una condición de carrera o peligro de carrera es una falla en un sistema o proceso por el cual la salida y / o resultado del proceso depende inesperadamente y críticamente de la secuencia o el momento de otros eventos. El término se origina con la idea de dos señales compitiendo entre sí para influir primero en la salida.

Creo que el punto clave para comunicar es que con frecuencia es un problema de tiempo que puede ser impredecible porque el tiempo que toma algo difiere de vez en cuando.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top