Можно использовать блокировки. Технология берёт lock на определённый ключ и начинает работу, другая технология при попытке взять lock видит, что он захвачен кем-то другим, и встаёт в очередь на ожидание результата.

Да, годное решение.

Это скорее не про ускорение, а про оптимизацию использования железки. Выхлопа по времени скорее всего не будет: технология либо будет собирать файл, либо будет ждать. Максимальный выигрыш - это разница между временем обработки одного файла и временем поступлением запроса на этот файл.
Т.е. реальная ситуация, где будет выхлоп: когда процесс обработки файла находится на стадии 99%, и в этот момент поступил на него запрос. Кажется, что это довольно редкий кейс.
Нужны замеры

@j0tunn мне кажется, что ты не прав, говоря, что выхлопа по времени не будет. Попробую объяснить почему на примерах.

Обработка

Давай для наглядности возьмём Stylus, он синхронный. Допустим мы хотим обрабатывать каждый файл по отдельности и сохранять результат в файлов кэш.

В случае, когда каждый бандл собирается независимо, то во время каждой обработки исходного файла остальные бандлы ждут. А когда дожидаются делают заново, то что только что было сделано.

Допустим у нас 100 исходных файлов и 10 бандлов. Что быстрее, обработать синхронно код 100 файлов или 1000 файлов?

А все (или почти все) операции обработки кода синхронные.

Чтение и запись

Кроме обработки каждый файл нужно прочитать с файловой системы и после обработки записать на файловую систему. Эта операция не синхронная, но и не бесплатная.

Если мы запустим асинхронно чтение 100 файлов или чтение 1000 файлов, в каком случае все файлы дочитаются быстрее?

Ресурсы

Даже если технология просто ждёт, то в это время другие технологии могут получить больше ресурсов и значит быстрее выполниться.

Нужны замеры

Я всегда за замеры, но не знаю как в данном случае что-то проверить, не реализовав механизм реиспользования.

Давай для наглядности возьмём Stylus, он синхронный

Это не так, рендеринг выполняется асинхронно. Для использования файлового кэша технологию Stylus нужно будет переписать так, чтобы каждый файл рендерился отдельно. Каждая операция - асинхронная. Кроме того для оптимизации можно запользовать JobQueue.

Даже если технология просто ждёт, то в это время другие технологии могут получить больше ресурсов и значит быстрее выполниться.

Это справедливо только если нам недостаточно ресурсов, т.е. грубо говоря мы упираемся, например, в CPU. Это легко проверить, @arikon недавно делал PR с возможностью мониторить CPU во время сборки

Я всегда за замеры, но не знаю как в данном случае что-то проверить, не реализовав механизм реиспользования.

Все твои выводы строятся на предположении, что будет одновременно большое количество (сотни) запросов на обработку одного и того же файла одной и той же технологией. Я предлагаю проверить это самое предположение. Можно взять текущую реализацию файлового кэша, впилить туда элементарный счетчик, запустить на большом проекте, проверить. Вангую что до десятка не дойдет.

И я еще раз предлагаю выполнять задачи последовательно. Этот issue - это оптимизация файлового кэша. Логичная последовательность такая: выпустить версию с файловым кэшом -> оптимизировать какую-нибудь технологию с использованием этого кэша (тот же stylus) -> провести замеры -> при необходимости запилить этот issue

Это не так, рендеринг выполняется асинхронно.

В каком месте оно асинхронное? Асинхронное API не значит асинхронный код, все операции с файлами, кэшом и т.д. синхронные.

Да, действительно, в stylus render по факту синхронный. Ну значит JobQueue в помощь.