2009-12-01 10 views
9

Leí en varios lugares que Boost.Signals no es seguro para la impresión de roscas, pero no he encontrado muchos más detalles al respecto. Esta simple cita no dice mucho. Actualmente, la mayoría de las aplicaciones tienen subprocesos, incluso si intentan ser de un solo subproceso, algunas de sus bibliotecas pueden usar subprocesos (por ejemplo, libsdl).Boost: ¿qué es exactamente inseguro en Boost.Signals?

Supongo que la implementación no tiene problemas con otros subprocesos que no acceden a la ranura. Por lo tanto, es al menos seguro en este sentido.

Pero, ¿qué funciona exactamente y qué no funciona? ¿Funcionaría usarlo desde múltiples hilos siempre que nunca acceda a él al mismo tiempo? Es decir. si construyo mis propios mutexes alrededor de la ranura?

¿O estoy obligado a usar la ranura solo en ese hilo donde lo creé? ¿O dónde lo usé por primera vez?

+0

Ha pasado un tiempo ... ¿mi respuesta a esto tenía sentido? Básicamente, la biblioteca de señales * en sí misma * no se bloqueará independientemente de las llamadas que realice desde cualquier conversación, siempre que sean "válidas" ... pero usted es responsable de la semántica en su propio código. – HostileFork

+0

Sí, tiene sentido, pero en realidad no responde todas mis preguntas. :) Básicamente dijiste "búscalo en la fuente". Haré eso en algún momento posterior y luego publicaré todas las respuestas exactas a mis preguntas aquí. – Albert

+0

Usted preguntó "¿qué funciona exactamente y qué no funcionaría?" Sentí que era más esencial que diseccionar sus preguntas más específicas.(Esas respuestas son "Sí: si guardas con un mutex que está bien, pero posiblemente innecesario si la semántica de tus máquinas tragamonedas es tal que más de un hilo puede ejecutarlas a la vez, es como llamar a cualquier otra función desde varios hilos" y "No: no está restringido al uso de máquinas tragamonedas solo en los hilos donde se crean".) – HostileFork

Respuesta

5

no creo que sea demasiado clara tampoco, y uno de los críticos de la biblioteca said here:

Asimismo, no le gusta el hecho de que sólo tres veces la palabra 'hilo' fue nombrado. Boost.signals2 quiere ser una biblioteca de 'señales seguras para hilos'. Por lo tanto, algunos detalles más y especialmente más ejemplos relativos a esa área se deben dar al usuario .

Una forma de averiguarlo es a go to the source y ver qué están usando _mutex/lock() para proteger. Luego imagina lo que pasaría si esas llamadas no estuvieran allí. :)

Por lo que puedo deducir, es asegurar cosas simples como "si un hilo está conectando o desconectando, eso no hará que un hilo diferente que se itera a través de las ranuras conectadas a esas señales se bloquee". Algo así como la forma en que el uso de una versión segura para subprocesos de la biblioteca C runtime asegura que si dos subprocesos realizan llamadas válidas al printf al mismo tiempo, entonces no habrá un bloqueo. (por no decir la salida que obtendrá hará ningún sentido — que sigue siendo responsable de la semántica de orden superior.)

no parece ser como Qt, en el que el hilo de una determinada ranura de El código que se ejecuta se basa en la "afinidad de subprocesos" del intervalo de destino (lo que significa que emitir una señal puede activar ranuras en muchos subprocesos diferentes para ejecutarse en paralelo.) Pero supongo que no respalda esa es la razón por la cual boost :: signal "combiners" puede do things like this.

0

Un problema que veo es que un hilo puede conectarse o desconectarse mientras otro hilo está señalizando.

Puede envolver fácilmente su señal y conectar llamadas con mutexes. Sin embargo, no es trivial para envolver las conexiones. (conecte las conexiones de devoluciones que puede usar para desconectar).