2010-07-22 14 views
12

Parece que el shared_mutex de Boost no es recursivo ... ¿Hay alguna forma de evitar esto? (sin volver a implementar todo el material)BOOST: recursivo shared_mutex?

+7

Antes de seguir este camino, es posible que desee leer lo que [otros piensan] (http://www.zaval.org/resources/library/butenhof1.html) sobre mutexes recursivos. –

+1

has mirado a boost: recursive_mutex? –

+1

Sí, pero no se ha compartido – GabiMe

Respuesta

-3

En esos casos, deberá usar shared_ptr. Ponga su mutex en un shared_ptr y hará ref-count en su mutex, lo que le dará resultados similares.

+0

¿cómo es un impulso :: weak_ptr relacionado con un impulso :: shared_mutex? –

+0

@Sam, lo siento, pensé en algo y escribí otro por completo. He editado mi publicación para que sea más clara/correcta. – Gianni

+3

'shared_ptr' no tiene nada que ver con la pregunta. La pregunta no se trata de compartir el objeto físico (que 'shared_ptr' permite) sino la propiedad compartida y resursiva del bloqueo (un concepto de sincronización en lugar de un objeto C++). –

0

boost :: recursive mutex es exclusivo. Creo que necesitarás extender shared_mutex. Puede mantener el ID del hilo actual en un conjunto y verificar si existe en el conjunto de la función que proporciona el bloqueo.

0

He estado en esta calle personalmente antes. La respuesta simple es no, no hay shared_recursive_mutex.

Realmente no estoy de acuerdo con lo que otros le dirán acerca de cómo los mutex recursivos son generalmente una mala idea, sin duda puede ahorrar algo de tiempo y evitar algunos errores. Sin embargo, si no desea implementar su propio shared_recursive_mutex, tendrá que quedarse con mutexes no recursivos. No es tan malo.

7

echar un vistazo a this thread y este excellent explanation por qué shared_mutex es una mala idea en general. entonces, si no está de acuerdo con que recursive_mutex también es una mala idea, simplemente úselo sin ninguna nitidez porque no le puede dar ningún aumento de rendimiento. recibirás incluso un código un poco más limpio sin cambios importantes.

Traté de usar shared_mutex en mi proyecto para bloquear el mapa altamente controvertido cuando muchos hilos suelen leer datos y rara vez lo modifican. recibió resultados de rendimiento un poco peores

+0

Sí. análisis muy interesante de hecho. ¡Gracias! – GabiMe

1

Estoy parcialmente en desacuerdo con Andy que shared_mutex es una mala idea porque depende de su diseño, es decir, cómo lo usa en su programa. Creo que si haces lecturas frecuentes con mutex compartido, puede brindarte un rendimiento más eficiente que si hubieras utilizado mutex simple para bloqueos cortos más frecuentes para leer con escrituras raras. Entonces shared_mutex es una forma de hacer algo largo simultáneamente. Y no creo que un candado largo sea un mal diseño en este caso.

¿Me apoya o estoy equivocado?