Как добавить элемент в отсортированный массив?

[voraa]

Странно это для клиентов будет.
Я посылаю запрос А передает С 10 бочек апельсинов.
Потом посылаю запрос С передает Д 5 бочек апельсинов.
Мне приходит ответ, что у С ничего нет. И я долго чешу репу, куда же они делись. Ведь он должен был от А получить 10.

[voraa]

Корректнее выполнять операции с участием С, когда остальные операции с его участием уже выполнились.

[webgraph]

а какая проверка делается в п.3? всей очереди, или только первого элемента?

и как извлекается первый элемента? как устроена очередь? если это просто массив с операцией shift, то может работать долго на длинной очереди.

Мы уже провели 100500 тысяч тестов и выяснили, что массивы чрезвычайно медленные. Для buffer идеальный кандидат Set(). Для pool — Map(). А так для обоих случаев может быть кандидатом и Object() — но он не всегда себя показывает достойно в тестах.

Т.к. в buffer (список обрабатываемых участников) хранятся только имена участников, то Set отлично подходит для этой задачи — как в реализации, так и в скорости.

В pool (очередь участников, которые не смогли попасть в buffer) у нас уже хранятся сами операции, состоящие из 2-х имен участников и действии, которые первый участник хочет сделать для второго. Т.к. Set может хранить только уникальные значения без ключей, то для pool подходит либо Map, либо Object.

[webgraph]

Странно это для клиентов будет.
Я посылаю запрос А передает С 10 бочек апельсинов.
Потом посылаю запрос С передает Д 5 бочек апельсинов.
Мне приходит ответ, что у С ничего нет. И я долго чешу репу, куда же они делись. Ведь он должен был от А получить 10.

Отправлять запрос может только сам участник инициатор операции — никто за него это сделать не сможет.

Если вы знаете, что вам участник А должен передать 10 бочек апельсинов, то очевидно же что вы не будете пытаться передать участнику Д 5 бочек, пока не убедитесь, что на вашем складе больше или равно 5 бочек.

[voraa]

то для pool подходит либо Map, либо Object.

А что для операции <A op B> в этом случае для Map является ключом, а что значением?
И как последовательно (или еще как) просматривать Map, не превращая его в массив?

Как можно просматривать этот пул? Взять одну операцию, посмотреть, может ли она быть выполнена, взять следующую и т.д.?

[webgraph]

Корректнее выполнять операции с участием С, когда остальные операции с его участием уже выполнились.

Что же в этом корректного? Исходя из такой логики операции вообще смогут никогда не выполниться, т.к. все будут постоянно друг друга ждать.

[voraa]

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

Нет не будут ждать. Как только очередная операция выполняется ее члены удаляются из буфера и просматривается очередь, на предмет того, какая операция может быть выполнена. Первая, которая может - выполняется. Можно и дальше просматривать, что бы послать на выполнение все, которые в этот момент могут быть выполнены. Но это гарантирует, что операции, например с участником А будут выполняться строго в последовательности, как они пришли.

[webgraph]

А что для операции <A op B> в этом случае для Map является ключом, а что значением?
И как последовательно (или еще как) просматривать Map, не превращая его в массив?

Как можно просматривать этот пул? Взять одну операцию, посмотреть, может ли она быть выполнена, взять следующую и т.д.?

Кстати да, неоднократно этот вопрос вставал как это делать. И сейчас пришла мысль — а может вообще отказаться от этого пула? Сейчас пришла такая мысль:

1. Если участников операции нет в buffer - добавляем в него и выполняем.
2. Если хотя бы один из участников есть в buffer, то делаем setTimeout() и пробуем до тех пор, пока не получится как в п.1

Причем это можно сделать как на стороне сервера, так и на стороне клиента.

[voraa]

2. Если хотя бы один из участников есть в buffer, то делаем setTimeout() и пробуем до тех пор, пока не получится как в п.1

Не самое лучшее, на мой взгляд, решение.
А пул - простой список.
Пришедшие операции добавляются в конец.
Есть два события: 1 - операция добавилась 2 - какая то операция выполнилась.
По каждому из этих событий мы просматриваем очередь от начала до конца. Если какая то операция может быть выполнена, то она отправляется на выполнение.

Опять же все завит от условий. Если в пуле десятки записей, то и массив с операциями push и splice будет прекрасно работать. Это внутренние хорошо оптимизированные операции.

[webgraph]

Не самое лучшее, на мой взгляд, решение.
А пул - простой список.
Пришедшие операции добавляются в конец.
Есть два события: 1 - операция добавилась 2 - какая то операция выполнилась.
По каждому из этих событий мы просматриваем очередь от начала до конца. Если какая то операция может быть выполнена, то она отправляется на выполнение.

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

В 99% случаев для каждого участника операции будет свободное место в buffer. А если и не будет - то оно очень скоро освободится.