La teoría
En teoría, cuando un hilo intenta bloquear un mutex y no tiene éxito, porque el mutex ya está bloqueado, se irá a dormir, permitiendo inmediatamente que se ejecute otro hilo. Continuará durmiendo hasta que se despierte, lo que será el caso una vez que el mutex esté desbloqueado por cualquier hilo que haya mantenido el bloqueo antes. Cuando un hilo intenta bloquear un spinlock y no tiene éxito, volverá a intentar bloquearlo continuamente, hasta que finalmente tenga éxito; por lo tanto, no permitirá que otro subproceso tome su lugar (sin embargo, el sistema operativo cambiará forzosamente a otro subproceso, una vez que se haya excedido la cantidad de tiempo de ejecución de la CPU del subproceso actual, por supuesto).
El problema
El problema con los mutexes es que poner los hilos en suspensión y volverlos a activar son operaciones bastante costosas, necesitarán muchas instrucciones de la CPU y, por lo tanto, también tomarán un tiempo. Si ahora el mutex solo estuvo bloqueado durante un período de tiempo muy corto, el tiempo dedicado a poner un hilo a dormir y despertarlo nuevamente podría exceder el tiempo que el hilo realmente ha dormido por mucho tiempo e incluso podría exceder el tiempo que el hilo haber perdido por sondear constantemente en un spinlock. Por otro lado, el sondeo en un spinlock desperdiciará constantemente el tiempo de la CPU y si el bloqueo se mantiene durante un período de tiempo más largo, esto desperdiciará mucho más tiempo de la CPU y hubiera sido mucho mejor si el hilo estuviera dormido.
La solución
El uso de spinlocks en un sistema de núcleo único / CPU simple generalmente no tiene sentido, ya que mientras el sondeo de spinlock esté bloqueando el único núcleo de CPU disponible, no se puede ejecutar ningún otro subproceso y dado que ningún otro subproceso puede ejecutarse, el bloqueo no ser desbloqueado tampoco. IOW, un spinlock desperdicia solo el tiempo de CPU en esos sistemas sin beneficio real. Si el subproceso se puso en reposo, otro subproceso podría haberse ejecutado a la vez, posiblemente desbloqueando el bloqueo y luego permitiendo que el primer subproceso continúe procesándose, una vez que se despertó nuevamente.
En un sistema multi-core / multi-CPU, con un montón de bloqueos que se mantienen solo durante un período de tiempo muy corto, el tiempo perdido para poner constantemente los hilos a dormir y despertarlos nuevamente podría disminuir notablemente el rendimiento del tiempo de ejecución. Cuando se usan spinlocks, los subprocesos tienen la oportunidad de aprovechar su cuántica de tiempo de ejecución completo (siempre solo bloquean durante un período de tiempo muy corto, pero luego continúan su trabajo de inmediato), lo que conduce a un rendimiento de procesamiento mucho mayor.
La práctica
Dado que muy a menudo los programadores no pueden saber de antemano si los mutexes o los spinlocks serán mejores (por ejemplo, porque se desconoce el número de núcleos de CPU de la arquitectura de destino), ni los sistemas operativos pueden saber si un cierto código ha sido optimizado para un solo núcleo o entornos multinúcleo, la mayoría de los sistemas no distinguen estrictamente entre mutexes y spinlocks. De hecho, la mayoría de los sistemas operativos modernos tienen mutexes híbridos y spinlocks híbridos. ¿Qué significa eso realmente?
Un mutex híbrido se comporta como un spinlock al principio en un sistema multinúcleo. Si un hilo no puede bloquear el mutex, no se pondrá a dormir inmediatamente, ya que el mutex podría desbloquearse muy pronto, por lo que el mutex primero se comportará exactamente como un spinlock. Solo si el bloqueo aún no se ha obtenido después de un cierto período de tiempo (o reintentos o cualquier otro factor de medición), el hilo realmente se pone a dormir. Si el mismo código se ejecuta en un sistema con un solo núcleo, el mutex no girará, aunque, como se ve arriba, eso no sería beneficioso.
Un spinlock híbrido se comporta como un spinlock normal al principio, pero para evitar perder demasiado tiempo de CPU, puede tener una estrategia de retroceso. Por lo general, no pondrá el hilo en suspensión (ya que no desea que eso suceda cuando use un spinlock), pero puede decidir detener el hilo (ya sea inmediatamente o después de un cierto período de tiempo) y permitir que se ejecute otro hilo , lo que aumenta las posibilidades de que el spinlock esté desbloqueado (un interruptor de hilo puro suele ser menos costoso que uno que implica poner un hilo a dormir y despertarlo más tarde, aunque no con mucha diferencia).
Resumen
En caso de duda, use mutexes, generalmente son la mejor opción y la mayoría de los sistemas modernos les permitirán hacer spinlock por un período de tiempo muy corto, si esto parece beneficioso. El uso de spinlocks a veces puede mejorar el rendimiento, pero solo bajo ciertas condiciones y el hecho de que tenga dudas, más bien me dice que no está trabajando en ningún proyecto en el que un spinlock pueda ser beneficioso. Puede considerar usar su propio "objeto de bloqueo", que puede usar un spinlock o un mutex internamente (por ejemplo, este comportamiento podría ser configurable al crear dicho objeto), inicialmente use mutexes en todas partes y si cree que usar un spinlock en algún lugar podría realmente ayuda, pruébelo y compare los resultados (por ejemplo, usando un generador de perfiles), pero asegúrese de probar ambos casos,
Actualización: una advertencia para iOS
En realidad, no es específico de iOS, pero iOS es la plataforma donde la mayoría de los desarrolladores pueden enfrentar ese problema: si su sistema tiene un programador de subprocesos, eso no garantiza que cualquier subproceso, sin importar cuán baja sea su prioridad, eventualmente tendrá la oportunidad de ejecutarse, entonces los spinlocks pueden conducir a puntos muertos permanentes. El planificador de iOS distingue diferentes clases de subprocesos y los subprocesos en una clase inferior solo se ejecutarán si ningún subproceso en una clase superior quiere ejecutarse también. No hay una estrategia de retroceso para esto, por lo que si tiene permanentemente subprocesos de clase alta disponibles, los subprocesos de clase baja nunca tendrán tiempo de CPU y, por lo tanto, nunca tendrán la oportunidad de realizar ningún trabajo.
El problema aparece de la siguiente manera: su código obtiene un spinlock en un subproceso de clase prio baja y, mientras está en el medio de ese bloqueo, el tiempo cuántico ha excedido y el subproceso deja de funcionar. La única forma en que este spinlock puede liberarse nuevamente es si ese subproceso de clase prio baja obtiene tiempo de CPU nuevamente, pero no se garantiza que esto suceda. Es posible que tenga un par de subprocesos de clase prio alta que desean ejecutarse constantemente y el programador de tareas siempre priorizará esos. Uno de ellos puede atravesar el spinlock y tratar de obtenerlo, lo cual no es posible, por supuesto, y el sistema lo hará ceder. El problema es: ¡un subproceso que produjo está inmediatamente disponible para ejecutarse nuevamente! Al tener un prio más alto que el subproceso que mantiene el bloqueo, el subproceso que mantiene el bloqueo no tiene posibilidad de obtener tiempo de ejecución de la CPU.
¿Por qué este problema no ocurre con mutexes? Cuando el hilo de prio alto no puede obtener el mutex, no cederá, puede girar un poco pero eventualmente será enviado a dormir. Un subproceso inactivo no está disponible para ejecutarse hasta que lo despierte un evento, por ejemplo, un evento como el mutex desbloqueado que estaba esperando. Apple es consciente de ese problema y, por lo tanto, ha quedado OSSpinLocken desuso . Se llama a la nueva cerradura os_unfair_lock. Este bloqueo evita la situación mencionada anteriormente, ya que conoce las diferentes clases de prioridad de subprocesos. Si está seguro de que usar spinlocks es una buena idea en su proyecto de iOS, use ese. Alejate deOSSpinLock! ¡Y bajo ninguna circunstancia implemente sus propios spinlocks en iOS! Si tiene dudas, ¡use un mutex! macOS no se ve afectado por este problema, ya que tiene un programador de subprocesos diferente que no permitirá que ningún subproceso (incluso subprocesos de bajo nivel de prio) se "ejecute en seco" en el tiempo de CPU, pero la misma situación puede surgir allí y luego conducirá a muy mal rendimiento, por lo tanto, OSSpinLockestá en desuso en macOS también.