¿Por qué no hay bloqueos de ámbito para múltiples mutexes en C++ 0x o Boost.Thread?

Question

biblioteca hilo C++ 0x o Boost.thread definen no miembro función de plantilla variadic que bloquear todos bloqueo evitando el bloqueo de muertos.

template <class L1, class L2, class... L3> void lock(L1&, L2&, L3&...); 

Si bien esta función ayuda a evitar a punto muerto, la norma no incluye el bloqueo de ámbito asociado a escribir el código de seguridad es una excepción.

{ 
    std::lock(l1,l2); 
    // do some thing 
    // unlock li l2 exception safe 
} 

Eso significa que tenemos que utilizar otro mecanismo como el bloque try-catch para hacer que el código de seguridad excepción o definir nuestra propia cerradura con ámbito en varios mutex nosotros mismos o incluso hacer que

{ 
    std::lock(l1,l2); 
    std::unique_lock lk1(l1, std::adopted); 
    std::unique_lock lk2(l2, std::adopted); 
    // do some thing 
    // unlock li l2 on destruction of lk1 lk2 
} 

Por qué la norma no incluye una cerradura restringidos en múltiples mutexes del mismo tipo, como por ejemplo

{ 
    std::array_unique_lock<std::mutex> lk(l1,l2); 
    // do some thing 
    // unlock l1 l2 on destruction of lk 
} 

o tuplas de mutexes

{ 
    std::tuple_unique_lock<std::mutex, std::recursive_mutex> lk(l1,l2); 
    // do some thing 
    // unlock l1 l2 on destruction of lk 
} 

¿hay algo malo en el diseño?

---

Actualizado: Descripción de la norma

template <class L1, class L2, class... L3> void lock(L1&, L2&, L3&...); 

Requiere: Cada tipo de parámetro de plantilla deberán cumplir los requisitos mutex, excepto que una llamada a try_- bloqueo() puede lanzar una excepción . [Nota: la plantilla de la clase unique_lock cumple estos requisitos cuando se crea una instancia adecuada. -finalizar]

Efectos: Todos los argumentos se bloquean mediante una secuencia de llamadas a lock(), try_lock() o unlock() en cada argumento. La secuencia de llamadas no dará como resultado un interbloqueo, pero de lo contrario no se especificará. [Nota: se debe usar un algoritmo de evitación de interbloqueo, como try-and-back-off, pero el algoritmo específico no se especifica para evitar implementaciones que restringen excesivamente. nota -fin] Si una llamada para bloquear() o try_lock() lanza una excepción, desbloquear() será llamada para cualquier argumento de que había sido bloqueado por una llamada para bloquear() o try_lock().

---

Acepto la respuesta. Entiendo que la razón principal es porque no hay tiempo suficiente para mejorar la biblioteca de Threads C++ 0x. Espero que TR2 incluya muchas más cosas.

Answer 1

creo que al proporcionar defer_lock_t (y adopt_lock_t) la expectativa es que el uso será como el segundo ejemplo, o probablemente más como:

std::unqiue_lock ul1(l1, std::deferred); 
std::unique_lock ul2(l2, std::deferred); 
std::lock(ul1, ul2); 

Esto es seguro excepción y todas esas cosas buenas.

Desde luego, no puedo pretender conocer la mente de los diseñadores, pero mi conjetura es que están haciendo un esfuerzo para proporcionar un conjunto mínimo de portátiles, caja fuerte, primitivas.Un tipo de cerradura con múltiples focos es solo una guinda, y es la guinda si se debe especificar y diseñar en el estándar, o en bobina de refuerzo. La formación de hielo debe implementarse (y por supuesto, el estándar debe preocuparse por implementación también, mira lo que sucedió con la exportación).

Answer 2

La construcción de un objeto que encierra múltiples cerraduras no evitar los puntos muertos más de lo que el bloqueo de forma individual. No puede bloquear dos bloqueos simultáneamente ... a menos que use dos hilos, lo que hace que el punto sea derrotado. Esto es cierto incluso si los pones en la misma declaración.