El patrón de diseño de objeto activo, según tengo entendido, está atando un tiempo de vida de hilo (privado/dedicado) con un objeto y lo hace funcionar en datos independientes. De la documentación que leí, la evolución de este tipo de paradigma se debió a dos razones: en primer lugar, manejar los hilos crudos sería doloroso y el segundo más hilos contendientes por el recurso compartido no se escalan bien usando mutex y bloqueos. aunque estoy de acuerdo con la primera razón, no comprendo completamente la segunda. Hacer que un objeto sea activo hace que el objeto sea independiente pero los problemas como la contención para lock/mutex continúan ahí (ya que todavía tenemos shared queue/buffer), el objeto acaba de delegar la responsabilidad de compartir en la cola de mensajes. La única ventaja de este patrón de diseño, como veo, es el caso en el que tuve que realizar una tarea de asin larga en el objeto compartido (ahora que estoy pasando el mensaje a una cola compartida, los hilos ya no tienen que bloquearse mucho en mutex/bloquea pero todavía bloqueará y contenderá para publicar mensajes/tarea). Aparte de este caso, alguien podría contar más escenarios donde este tipo de patrón de diseño tendrá otras ventajas.¿Para usar el objeto activo o no?
La segunda pregunta que tengo es (acabo de empezar a buscar patrones de diseño), cuál es la diferencia conceptual entre el objeto activo, el reactor y el patrón de diseño del proactor. ¿Cómo se decide en qué patrón de diseño es más eficiente y se adapta más a sus necesidades? Sería realmente agradable si alguien puede demostrar ciertos ejemplos que muestran cómo se comportarán los tres patrones de diseño y cuál tiene ventaja/desventaja comparativa en diferentes escenarios.
Estoy un poco confundido porque utilicé el objeto activo (que usó el búfer compartido seguro para subprocesos) y boost :: asio (Proactor) para hacer cosas asincrónicas similares, me gustaría saber si alguien tiene más información sobre la aplicabilidad de diferentes patrones al abordar un problema.