Nombre esa técnica (se puede llamar 'piggybacking')

¿Cuál es el nombre del siguiente método/técnica (trataré de describir lo mejor que pude, probablemente se necesite información sobre "memoización" para comprender por qué esta técnica puede ser muy útil):Nombre esa técnica (se puede llamar 'piggybacking')

iniciar algunos computación asíncrona potencialmente devuelvan todo y se da cuenta que un cálculo idéntico ya se ha iniciado pero no está hecho todavía y que "a cuestas" en el primer cálculo. Luego, cuando termina el primer cálculo, no emite uno sino dos devoluciones de llamada.

El objetivo es no iniciar innecesariamente un segundo cálculo porque sabe que ya se está ejecutando un cálculo idéntico.

Tenga en cuenta que aunque no del todo diferente, no estoy buscando el caso particular de almacenamiento en caché que "memoria" es: memoria es cuando comienza un cálculo y encuentra un resultado en caché (memoized) de ese mismo cálculo que es ya hecho que puede reutilizar.

Aquí estoy buscando el nombre de la técnica que sea en cierto modo similar a la memorización (en el sentido de que puede ser útil por algunos de los mismos motivos por los que la memorización es una técnica útil), excepto que reutiliza el resultado del primer cálculo , incluso si el primer cálculo no se ha realizado aún en el momento de emitir el segundo cálculo.

Siempre he llamado a esa técnica "piggybacking" pero no sé si esto es correcto.

En realidad, he usado esto más de una vez como algún tipo de "memoria sobre esteroides" y me ha resultado muy útil.

Simplemente no sé cuál es el nombre de esta técnica (¿avanzada?).

EDITAR

Maldición, quería hacer comentarios sobre la respuesta de epatel pero desapareció. La respuesta de epatel me dio una idea, esta técnica podría ser llamado "memoization perezoso" :)

Fuente

2010-03-04 cocotwo

¿Cancelación del hilo? –

@Robert Harvey: googleando en "Cancelación de subprocesos" :) hummm ... El problema es que la cancelación de subprocesos tiene mucho significado y que, dependiendo de la implementación, es posible que no se inicie en absoluto el segundo subproceso asincrónico largo porque estás directamente a cuestas en el otro. – cocotwo

He visto "piggybacking" usado en un contexto diferente pero por la misma idea: el recién llegado aprovecha la sobrecarga que ya ha sido (o está siendo) pagado por otra persona. No permita que eso le impida encontrar o definir un trabajo particular para su contexto. –

suena como un futuro: http://en.wikipedia.org/wiki/Future_%28programming%29

Fuente

2010-03-04 23:31:04 ergosys

@ergosys: es más complicado que un Futuro. Un futuro es útil, por ejemplo, para mostrar una barra de progreso o el resultado de un cálculo. Aquí está tener un segundo cálculo "piggyback" * sobre el futuro de la primera computación *. – cocotwo

suena un poco como Lazy Evaluation, pero no exactamente ...

Fuente

2010-03-04 23:32:17 epatel

En algunos contextos, he escuchado esto llamado "Solicitud de fusión".

Fuente

2010-03-05 00:10:53 caf

Esto es solo memoria de futuros.

normal memoization "ansiosos" funciona así:

f_memo(x): 
    critical_section: 
    if (exists answers(f,x)) 
     return answers(f,x) 
    else 
     a = f(x) 
     answers(f,x) = a 
     return a

Ahora bien, si f (x) devuelve futuros en lugar de los resultados reales, el código anterior funciona como es . Se obtiene el efecto cuestas, es decir, como esto:

primer subproceso llama f (3)
No hay una respuesta almacenada para f (3), por lo que en la sección crítica que hay una llamada a f (3) .f (3) se implementa como devolver un futuro, por lo que la 'respuesta' está lista inmediatamente; 'a' en el código anterior se establece en el futuro F y el futuro F se almacena en la tabla de respuestas
El futuro F se devuelve como el "resultado" de la llamada f (3), que es potencialmente todavía en curso
Otro subproceso llama f (3)
el futuro F se encuentra de la mesa, y devuelto inmediatamente
Ahora ambos hilos tienen identificador para el resultado del cálculo; cuando intentan leerlo, bloquean hasta que el cálculo esté listo --- en la publicación se menciona que este mecanismo de comunicación fue implementado por una devolución de llamada, presumiblemente en un contexto donde los futuros son menos comunes

Fuente

2010-03-05 05:39:06

Exactamente lo que pensé al leer la pregunta. Los futuros no se usan tanto, pero son muy prometedores (si se obtienen hilos baratos como corutinas). –

@ antti.huima: Supongo que depende de lo que prefiera: tener dos hilos (o más) bloqueados para esperar un futuro (que es lo que Matthieu M insinúa: necesita hilos baratos) o para sondear un futuro "ya está hecho" o para usar la notificación de devolución de llamada instantánea al finalizar. Estoy de acuerdo en que cuando se implemente utilizando el futuro es una "memoria de futuros", pero el futuro no es la única forma de hacerlo. Estoy usando algo más parecido a una devolución de llamada "ProgressOrResultHandable", que desde un punto de vista de transmisión de mensajes es en mi humilde opinión mucho más limpia que el futuro. Sin bloqueo, sin tiempo de espera, sin votación. Solo notificación de devolución de llamada instantánea. – cocotwo

@cocotwo devoluciones de llamada son de hecho más limpios si está programando de una manera impulsada por eventos. Los futuros se usan cuando los hilos y el paralelismo son comunes y de otro modo son inútiles. Por ejemplo, considere: para (i = 0; i <100; i ++) páginas [i] = fetch_web_page (url [i]); si fetch_web_page genera un hilo y devuelve un futuro, ¡esto se paraleliza automáticamente sin más construcciones de programación! En la práctica, los futuros apoyarían la consulta si están listos, es decirmás tarde, puede solicitar is_ready (páginas [i]) para informes de progreso sin bloqueo; bloqueas cuando realmente accedes a los resultados. –

Nombre esa técnica (se puede llamar 'piggybacking')

Respuesta

Cuestiones relacionadas