Una concurrencia fluida Revolución con Objetos Gratis

El avance tecnológico de los multinúcleo permite acelerar el tiempo de ejecución de un programa, pero esto depende de la
programación concurrente.

Programa cómo una colección de objetos “libres”, cada uno de los cuales tiene su propio hilo de control y ejecuta sus operaciones
dentro de las transacciones atómicas.

La apasionante vida de un aristócrata de la concurrencia

Edsger Dijkstra, C.A.R Hoare y otros dieron forma al campo de la concurrencia. Podemos clasificar de forma muy aproximada los
modelos que los investigadores han estudiado como:

• hilos y cerraduras,

• estructuras de datos sin bloqueo,

• transacciones,

• actores, y

• objetos activos.

Son un poco lejanos de la aplicación común en el mercado.

Hilos y cerraduras

Los programas son ejecutados cómo un conjunto de subprocesos accediendo a estructuras de datos compartidas de manera simultanea
que son protegidos por un candado(lock). Los hilos son mapeados a procesadores de acuerdo con alguna estrategia que típicamente
depende en el sistema operativo real y arquitectura de hardware, sigue siendo restringida a programas específicos y plantea varias
preguntas difíciles, incluido exactamente cuándo bifurcar un hilo, como descomponer un programa en subprocesos simultáneos y
cuándo adquirir cerraduras. Bloqueo de grano grueso conduce a soluciones ineficientes, mientras que el bloqueo detallado conduce a
programas propensos a errores.

Además, las cerraduras no son robustas: un hilo que se intercambia hacia afuera mientras mantiene un candado evita que otros hilos
que luchan por la misma estructura de datos de hacer cualquier progreso.

Estructuras de datos sin bloqueo

Los programas se estructuran como conjuntos de hilos que se sincronizan sus actividades usando nonblocking estructuras de datos.
Esta característica evita el problema de robustez del bloqueo. hacer uso de (o más bien, asumiendo) atómica de bajo nivel Objetos,
como registros y operaciones de comparación e intercambio. Diseñar estructuras de datos sin bloqueo no es trivial; de hecho, las
implementaciones eficientes de tales estructuras son publicables como resultados en conferencias como la ACM Conferencia sobre
Principios de Computación Distribuida (PODC) y el Simposio Internacional sobre Computación Distribuida Informática (DISCO).
Considerando que es razonable suponer que los programadores expertos pueden diseñar y utilizar bibliotecas de estructuras de datos
sin bloqueo — Maurice Herlihy y Nir Shavit pronto a ser publicado El arte de La programación multiprocesador ciertamente ayudará; no
es realista preguntar desarrolladores comunes para convertir todas sus clases potencialmente compartidas en otras que no bloqueen.

Actas/ Transacciones

Las transacciones han existido durante algún tiempo, y no solo en bases de datos

Barbara Liskov los incorporó en su idioma Argus una forma sencilla de hacer un bloque de código atómico y sin bloqueo. Básicamente,
una transacción es una unidad lógica de cálculo que se puede abortar de forma segura. Por lo tanto, podemos implementar
transacciones sin cerraduras subyacentes, simplemente cancelarlos y volver a intentarlos en caso de que las fuertes sospechas indican
que se ha producido un interbloqueo o que se ha detectado un subproceso que participa en la transacción. cambiados. Dado que esto
puede llevar a live-locks, en el que las transacciones se abortan mutuamente, interesante la investigación en curso está explorando
cómo diseñar gestores de contención que puedan adoptar estrategias para reintentar transacciones abortadas en el momento
adecuado o con la prioridades correctas, basadas en la antigüedad de la transacción o cuántos objetos tiene realmente accedido, una
transacción que comenzó antes o accedió a un mayor número de objetos debe tener una prioridad más alta. Los modelos de
transacción, sin embargo, dejan abierta la pregunta de cómo para descomponer una aplicación en un conjunto

Actores

Siguiendo una dirección antropomórfica iniciada por Gul Agha y Carl Hewitt hace más de dos décadas,
los desarrolladores que usan este enfoque construyen programas concurrentes como conjuntos de actores comunicantes. Esta
actividad no incluir bifurcación de subprocesos explícitos; en cambio, cada actor implícitamente tiene su propio hilo y se comunica
asincrónicamente con otros actores por intercambiando mensajes. Cuando recibe un mensaje, un actor ejecuta algún comportamiento,
posiblemente envía un mensaje a otro actor, y luego se convierte en un nuevo actor. haciendo el ultimo operación el único punto de
estado el cambio simplifica significativamente el control de concurrencia dentro de un actor: el actor es, en este sentido, apátrida. Sin
embargo, programar una aplicación en términos de mensajería asíncrona y los objetos sin estado no son triviales, en

Una forma de ver una transacción es como una simple forma de hacer un bloque de código atómico y sin bloqueo Una transacción es
una unidad lógica. de cálculo que se puede abortar de forma segura.

Hacia la integración menos, la brecha entre este modelo y un programa OO típico no está claro. ¿Cómo transformas un programa hecho
de objetos secuenciales con estado que interactúan de manera sincrónica en un sistema de actores apátridas que se comunican
asincrónicamente? ¿Cómo agrupar varios actores dentro del misma entidad lógica sin sistemáticamente creando actores más grandes
para abarcar todo el cálculo, por ejemplo, programar una transacción atómica que se retira y luego deposita dinero dentro de dos
diferentes actores? No hay respuestas simples a estas preguntas.

Objetos activos

A diferencia de un actor, un objeto activo es típicamente con estado. digo "típicamente" porque ha habido casi como muchos modelos
de objetos activos como papeles sobre el tema, y había de hecho, muchos documentos sobre este tema 10 años atrás en la Conferencia
ACM sobre Sistemas, Lenguajes y Aplicaciones de Programación Orientada a Objetos (OOPSLA) y la Conferencia Europea sobre
Programación Orientada a Objetos (ECOOP). Moviéndose de un programa secuencial OO a un programa de objetos activos (con estado)
es bastante natural con pocas excepciones. Porque el objeto activo es stateful, teniéndolo controlar explícitamente su concurrencia a
evitar obstaculizar la encapsulación es tentador. Por ejemplo, podríamos desea enriquecer la interfaz de un objeto para expresar
patrones como “ciertas operaciones no pueden ejecutarse simultáneamente” o “alguna operación no puede ejecutar en un cierto
estado.” Podríamos también expresa el hecho de que una operación de obtención no se puede ejecutar en un vacío buffer. Como
señalaron Satoshi Matsuoka y Akinori Yonezawa,1 este plantea más problemas al extender las interfaces. Por ejemplo, para agregar un
operación gget (digamos, a través de la herencia) que se puede ejecutar solo después de obtener exactamente uno, debemos modificar
el original llegar a recordar exactamente cuando Fue ejecutado. Por otra parte, aunque la atomicidad de una operación de objeto
parece fácil de asegurar si la operación es puramente local, la situación es más complicado si la operación implica varios otros objetos
activos.

¿Qué objetos son gratuitos?

Podríamos imaginar tres maneras diferentes distinguir entre objetos que son gratuitos y los que no lo son:

• Todos los objetos de ciertas clases o los tipos son gratis. el programador tendría que destacar cuales las clases/tipos de objetos son
gratuitos — decir, haciéndolos heredar de alguna clase/tipo de ancestro específico.

• El creador del objeto decide si este último es gratuito. El creador puede decidir si "desatar" el nuevo objeto utilizando una nueva
construcción específica, digamos fnew, proporcionada como una primitiva del lenguaje.

• En un mundo ideal, el objeto recién creado decidiría si era gratis o no. Podríamos usar constructores específicos para lograr esto. Para
entender el modelo de objeto libre, otra pregunta está en orden.

datos + funciones + hilo + transacción = objeto libre