Нашел их, пока копал рантайм для серии статьей, которую пишу для хабра. В статью влезет только один, и то одним абзацем, так что вот оба целиком.
Первый 💃
Живет в
findRunnable, функции, которой каждый поток ищет себе работу proc.go:3622. Ситуация такая. Поток не нашел горутин, покрутился вхолостую и решил засыпать. Ровно в этот момент другой поток кладет новую работу в очередь, проверяет, есть ли кто-то бодрствующий, видит нашего (тот еще числится крутящимся) и потому никого не будит. Через миг наш засыпает. Работа лежит, все спят.Комментарий в коде диктует порядок действий:
We must drop nmspinning first and then check all sources again (with #StoreLoad memory barrier in between). If we do it the other way around, another thread can submit work after we've checked all sources but before we drop nmspinning; as a result nobody will unpark a thread to run the work.
Сначала снять с себя признак крутящегося, потом барьер памяти
StoreLoad, потом заново перепроверить все источники работы: локальные очереди, глобальную, таймеры, работу сборщика мусора. Обратный порядок ломает все.Второй 💃🏻
Живет в
acquireSudog proc.go:488, и он смешнее:Delicate dance: the semaphore implementation calls acquireSudog, acquireSudog calls new(sudog), new calls malloc, malloc can call the garbage collector, and the garbage collector calls the semaphore implementation in stopTheWorld.
Семафор зовет
acquireSudog, тот зовет new, new зовет malloc, malloc может запустить сборщик мусора, а сборщик в stopTheWorld зовет семафор. Кольцо замкнулось. Рвут его грубо: на время new(sudog) поднимают счетчик m.locks, и сборщик просто не может стартовать.Читать рантайм ради таких комментариев отдельное удовольствие. Редкий жанр, где инженер объясняет не что делает код, а от какого именно невоспроизводимого ужаса он защищает...