Lock Convoy

Você sabe o que é Lock Convoy? (Dica: não tem nada a ver com os locks e bloqueios do SQL Server).

Já havia presenciado esse problema na faculdade. Fomos fazer um trabalho em grupo com 20 pessoas. A matemática era que, se uma pessoa conseguiria fazer o trabalho em 8 horas, então terminaríamos em questão de minutos ao juntar 20 pessoas. O resultado foi exatamente o oposto. Demoramos mais tempo discutindo a distribuição de tarefa ao invés de fazer a tarefa. Lock convoy!

Esse comportamento chamado LOCK CONVOY ocorre quando várias threads tentam acessar um mesmo recurso e perdem mais tempo do que se fosse apenas por uma thread. Seria algo como uma "escalabilidade negativa" devido ao bloqueio.

Enquanto levantava referências, encontrei outras variações para esse comportamento, como por exemplo: Thundering herd problem (Wikipedia). Lá encontramos uma referência para a ocorrência do problema no Linux.

A discussion of this observation on Linux
https://lkml.org/lkml/2004/5/2/108

Esse problema não é uma exclusividade do Linux. Enfrentamos um problema similar no Kernel do Windows ao trabalhar com uma limitação do dispatcher lock, mas que foi resolvido pelo Arun Kishan.

Arun Kishan
https://channel9.msdn.com/shows/Going+Deep/Arun-Kishan-Farewell-to-the-Windows-Kernel-Dispatcher-Lock/

O problema é minimizado no SQL Server usando uma execução de thread em modo cooperativo.

SQL Scheduler: Cooperative Mode
https://blogs.msdn.com/b/fcatae/archive/2011/03/09/sql-scheduler-cooperative-mode.aspx

Solução (?)

A solução é ser mais rápido (individualmente) ou diminuir o paralelismo. No caso de computadores, podemos usar processadores com clocks mais rápidos. Note que isso é ligeiramente diferente de adicionais mais CPU ou Cores.

No próximo post, vou ilustrar esse comportamento usando um exemplo do nosso cotidiano (pelo menos em São Paulo se aplica quase que diariamente) – o trânsito de carros.