Тут все дело в конкретных условиях. Если в очереди тысячи запросов, то как то надо оптимизировать. Если десятки, то вся эта оптимизация съесть все время.

При освобождении А и Б, из очереди немедленно будет забрана задача А-Б. Запрос Б-А никак не сможет воткнуться между этими действиями и в любом случае добавляется в очередь.

Меня тут больше смущает другой кейс: обрабатывается А-Б, в очереди сидит А-С, пришёл запрос С-Д. Вроде как он свободен и можно запускать, но тогда для участника С он выполнится до предыдущего. Если так нельзя, то надо проверять участников не только в хешмэпе текущих обрабатываемых, но ещё в хешмэпе персональных очередей, о котором я говорил выше. И если там нашлось, то ставить в очередь.

Ну это понятно :) мы тут обсуждаем оптимизацию, предполагая что там дохрена всего и оптимизировать надо )

Ну если там ТАК много запросов, тут тут уж пора кластеризацию обсуждать, микросервисы там, Redis, Kafka, связность, отказоустойчивость... :D

А на деле у автора вопроса там по 3,5 запроса в час.)

И всего этого можно избежать, если просто сразу поставить в очередь

Для чего использовать эти комбайны? Одно дело, когда запросов приходит много и они всякие разные. И совершенно другое дело, когда запросов приходит много одинаковых.

Это тоже самое, что использовать WordPress или Bitrix для одностраничного сайта с одним номером телефона. Мало того, что они сами по себе тормозы лютые, так и ещё самое главное — зачем?

Готовые решения здесь совершенно неуместны, потому что они все избыточны, создают дополнительные зависимости, требуют бОльших мощностей и значительно отбирают скорость.

Исходя из логики программы — большинство запросов должны быть уникальными и выполняться сразу без использования очередей. Но мы должны быть готовы и к внеплановым ситуациям.

Лучшим решением всегда будет то, что создано специально под конкретную задачу с нуля.

Здесь играет роль только то, есть ли участники нового запроса в buffer или нет. Исходя из вашего примера С-Д выполнится первее, чем А-С, и это совершенно нормальное и правильное положение событий. Кто первый встал, того и тапки, как говорится.

Исходя из выше сказанного
это не так
А сначала должен что то передать С, что бы потом С мог передать это Д
Если сначала выполнять С-Д, то у С может этого не быть.
Задачу на корректнее ставить.

Так проверка наличия чего-либо проверяется как раз в момент операции. И эти данные участников хранятся в другом месте, не в очереди.

Если в момент операции выясняется, что у С нет того, что надо передать Д, то будет возвращен ответ "Операция не выполнена — не достаточно того-то".

И какой смысл С что-то передавать Д, если у него этого нет? Только если для DDOS-атаки.

Более того, т.к. операции выполняются считанные микросекунды, то выполнять предварительную проверку "Есть ли у С то, что он хочет передать Д?" перед добавлением в buffer — некорректно. Проверка может сказать "ДА, True, у C есть то, что он хочет передать Д", но пока эта проверка проводилась, то успела произойти другая операция и по итогу у С уже нет того, что он хочет передать Д.