Bueno, creo (y hay varios estudios) que el STM actual no es más rápido que el código sin bloque y basado en mutex. Es obvio: STM requiere verificación de conflictos de datos en línea. Sin embargo, tal comprobación de conflictos en software puro requiere mucho tiempo de gastos generales. Actualmente, solo el ROCK processor de Sun admite una forma limitada de STM (Best-effort HTM con STM) por hardware. Actualmente, ninguna CPU x86 admite TM en el hardware. En resumen, STM es simplemente lento.
En mi opinión, será mejor que utilice una tabla hash concurrente. Por ejemplo, puede encontrar concurrent_hash_map en Intel TBB. Aquí está el enlace de TBB Manual. Oh, pero es C++, no C. Pero, sí creo que puedes (aunque podría requerir mucho trabajo) traducir esa tabla hash basada en C++ al código C. Intel TBB es de código abierto.
Además, creo que estructuras de datos tan concurrentes (generalmente implementadas como libres de bloqueos) no siempre son útiles. En algunos patrones de carga de trabajo, el uso de tales estructuras de datos no es bueno. Para estar seguro, le recomiendo que escriba una pequeña micro-referencia para dos versiones de tablas hash: (1) sin bloqueo y (2) basado en bloqueo. Además, tenga en cuenta que los patrones de carga de trabajo para dicho micro-benchmark deberían ser cercanos a uno real. Un ejemplo se puede encontrar en here.
¿Quiso decir STL en lugar de STM? –
Creo que se refiere a STM - Software Transactional Memory - ya que está buscando cosas como instantáneas y reintentos automáticos: http://en.wikipedia.org/wiki/Software_transactional_memory Pero probablemente debería dejar eso en claro, ya que STM no es una área muy conocida. –
Corregido la descripción. Michael tiene razón. – viraptor