(Consulta) Mejor forma de implementar el algoritmo con programación concurrente

Iniciado por class_OpenGL, 2 Julio 2017, 15:28 PM

0 Miembros y 1 Visitante están viendo este tema.

class_OpenGL

Hola a tod@s. Estoy introduciéndome en el mundo de la programación concurrente usando los hilos de POSIX. Estoy intentando implementar de forma segura lo siguiente:

Thread 1 (hilo POSIX): actualizar framebuffer (búfer de pantalla)
Thread 2 (hilo principal): actualizar imagen con una proveniente de una cámara.

El framebuffer se actualiza con la imagen leida de la cámara. Entonces, una secuencia de ejecución sería algo parecido a:

|-----Actualizar imagen-----|-----Actualizar imagen-----|-----Actualizar imagen-----|
|--------Actualizar framebuffer--------|--------Actualizar framebuffer--------|--------Actualizar framebuffer--------|

Es posible que actualizar el framebuffer ocupe menos tiempo que actualizar la imagen, no se sabe.

Entonces mi pregunta es: ¿cuál creen que es la mejor forma de actualizar el framebuffer sin que haya tearing (se mezcle el frame anterior con el actual)?

Lo ideal sería que fuera lo más eficientemente posible, es decir, que si ya se ha leido una imagen, el actualizador del framebuffer no tenga que esperar a que se lea otra imagen.

No pido que me den código, solo pregunto cual sería la idea de implementación (no sé si me explico)

Programador aficionado. Me quiero centrar en programar videojuegos. La API que uso para crearlos es OpenGL

ivancea96

Si tenemos los 2 threads separados, en adelante logica y renderizado, puedes tener un objeto  al que tengan acceso ambos con la imagen (y además, todas las variables necesarias para la sincronización de los threads al acceder a este).

Luego, cada uno trabaja por su lado:
- La lógica leerá la imagen en su propio objeto. Cuando termine, lo asignará al objeto compartido, y eliminará el anterior si lo hubiere (un simple swap a un puntero atómico serviría).
- El renderizado cogerá el objeto (si lo hubiere), y lo renderizará. Al finalizar, lo elimina (o utiliza otro thread como recolector de basura, como veas). Si no hubiese aun objeto, pues una de dos, o esperas, o renderizas el anterior. A gusto del consumidor (literalmente, esto es un problema productor-consumidor). La verdad, es que con solo esta información, no hay mucho más margen de posibilidades.

De todos modos, si te estás iniciando a programación concurrente, trabajar con la gráfica es el último lugar en el que empezaría. Conviertes un problema trivial en un problema más complejo.

Por cierto, con respecto a esto, hay un vídeo de la CPPCON que trata este tema, aunque de forma más profunda: https://www.youtube.com/watch?v=8AjRD6mU96s

class_OpenGL

Si, tienes razón! Debería empezar por algo más sencillo. ¿Por dónde recomendarías empezar? ¿Sabes de una buena página con buenos ejercicios? Eché un ojo pero no vi demasiados buenos ejercicios. Gracias

Programador aficionado. Me quiero centrar en programar videojuegos. La API que uso para crearlos es OpenGL

ivancea96

Cita de: class_OpenGL en  2 Julio 2017, 19:36 PM
Si, tienes razón! Debería empezar por algo más sencillo. ¿Por dónde recomendarías empezar? ¿Sabes de una buena página con buenos ejercicios? Eché un ojo pero no vi demasiados buenos ejercicios. Gracias

No conozco, pero vaya. Siempre puedes haacer un contenedor de cualquier tipo y hacerlo thread-safe :D
O un algoritmo, como QuickSort.

Otra opción es hacer algún tipo de juego/chat/pizarra online; el servidor puede llevar threads, que escribirán y leerán datos continuamente de los "datos de la sesión".

class_OpenGL


Programador aficionado. Me quiero centrar en programar videojuegos. La API que uso para crearlos es OpenGL