SoloCodigo

Hola, que tal.

Desarrollando una aplicacion, estoy usando una API de sonido que permite crear un stream(llenar el buffer) de manera asincrona sin bloquear la apliación, y una vez ha terminado, llama a un callback para procesar el sonido. Mi duda viene de que no entiendo muy bien como lo hace internamente. Para ser sinceros comprendo lo que significa hacerlo asíncrono, pero no así la manera de llevarlo a cabo.

Lo que he pensado es que quizas lo que hace es que, si se le especifica que no sea bloqueante, crea un nuevo thread para procesar esa petición y cuando termina llama a la funcion callback, de mientras el mainthread sigue su curso.

Se que no es muy bien una duda específica de C, es solo que me gustaría entender la filosofia de las llamadas asíncronas y como son tratadas. Más que nada para saber un poquito más.

No se si podriais explicarme un poco como funcionan las llamadas asíncronas.

He leido un par de links sobre esto, pero no acaba de quedarme claro del todo.

Gracias de antemano

Si, como yo tampoco lo tengo estoy un poco jodido xD, pero bueno, era más que nada para saber. Había leido que una forma sencilla era implementarlo con hilos, pero no me imagino una manera de hacer algo asíncrono sin hilos, quiero decir, si una aplicacion es ejecutada secuencialmente, no lo veo muy viable.

Gracias  

Hola rfog.

Si, entiendo como funciona una callback, lo que me mantiene un poco más en vilo es como la función logra desvincularse para hacer su tarea en segundo plano. Son un poco manias mias, ya seguiré investigando.

Gracias por la información =)

Aún así estás usando multihilo o multiproceso, aunque sea de forma transparente

Igualmente estoy casi convencido que lo hará con hilos u otro proceso si no necesita acceder a la memoria/código de tu proceso.

Segun tengo entendido, los hilos a diferencia de los procesos, comparten memoria y código, no? Así que no habría mucho problema si un hilo auxiliar necesita modificar, por ejemplo, una variable global.

Cita de: "m0skit0"

Aún así estás usando multihilo o multiproceso, aunque sea de forma transparente

Igualmente estoy casi convencido que lo hará con hilos u otro proceso si no necesita acceder a la memoria/código de tu proceso.

Segun tengo entendido, los hilos a diferencia de los procesos, comparten memoria y código, no? Así que no habría mucho problema si un hilo auxiliar necesita modificar, por ejemplo, una variable global.

Así es. No sólo variables globales, sino variables de instanca y objetos. Un hilo tiene su propia pila pero comparte el montículo global de la aplicación, aunque si quieres puede tener un montículo aparte, así como TLS (Thread Local Storage), al menos en Windows.

Y sí, puedes acceder a cualquier objeto global o de instancia con visibilidad (un hilo no es más que una función que se ejecuta de forma "simultanea" con otras), pero ten en cuenta que tienes que "sincronizar" el acceso, porque un hilo podría leer una variable mientras que otro la está modificando y el resultado queda indeterminado.

La forma más sencilla de sincronizar es tener unos "flags" que indiquen cuándo un hilo está modificando. Aunque la forma correcta son las secciones críticas, los mutex y los semáforos.

Y declara todas las variables que vayan a usar diferentes hilos como "volatile" o podrías tener problemas en entornos multicore o multiprocesador.

Sí, volatile es para indicarle al compilador que esta variable puede cambiar de valor de forma asíncrona, por tanto no puede fiarse de la caché de instrucciones por ejemplo.

EDITO: caché de datos quiero decir

volatile no tiene nada que ver con POSIX, es algo del compilador.

Yo había he usado hilos, en códigos mios para aprender, y si que se que para modificar secciones críticas lo mejor es bloquear el mutex y luego desbloquearlo, lo que no sabía es que las variables debían ser volatiles.

Saludos

Eso es porque nunca lo has probado en entornos multicore o multiprocesador... Hasta en un micro HyperThreading no hay problema porque comparten caché y memoria, pero con un sistema multiprocesador sí, y más todavía si utiliza arquitectura numa completa. En ese caso, dependiendo del compilador, ni siquiera con volatile es suficente.

Con todo, al menos Visual C++ es lo suficientemente inteligente como para detectar el uso de una variable compartida y optimizarla sin perder la sincronización.

Respecto a los mutex, al menos en Windows son objetos del núcleo y son caros en tiempo de proceso y de ejecución, por lo que para sincronización entre hilos de un mismo proceso se recomiendan las secciones críticas porque son objetos locales mantenidos por el compilador y el runtime, mucho más rápidos y eficientes.