update README.md for smartsched

This commit is contained in:
Pavel Danilov 2022-04-07 11:39:26 +00:00 committed by Fedor Korotkiy
parent a9f3a568e4
commit dd1c82f1cf

View file

@ -36,20 +36,33 @@
Ожидающий исполнения джоб всегда находится в первой локальной очереди воркеров, на которых есть Ожидающий исполнения джоб всегда находится в первой локальной очереди воркеров, на которых есть
результаты работы этого джоба. результаты работы этого джоба.
Если джоб ждёт выполнения дольше `CacheTimeout` или если в момент `SchedulerJob` джоба не было в кеше ни на одном Если выполнено одно из следующих условий, то джоб попадает во все вторые локальные очереди воркеров, на которых есть
из воркеров, то он попадает во все вторые локальные очереди воркеров, на которых есть хотя бы один артефакт хотя бы один артефакт из множества зависимостей этого джоба:
из множества зависимостей этого джоба.
1) В момент вызова `ScheduleJob` джоба не было в кеше ни на одном из воркеров
2) Джоб ждёт выполнения дольше `CacheTimeout`
Определения первой и второй локальной очереди не зависят от того, в каком порядке в шедулер пришли джобы Определения первой и второй локальной очереди не зависят от того, в каком порядке в шедулер пришли джобы
и информация о кеше артефактов. То есть, если джоб уже находится в глобальной очереди и в этот момент приходит и информация о кеше артефактов. То есть, если джоб уже находится в глобальной очереди и в этот момент приходит
информация, что этот джоб находится в кеше на воркере `W0`, то джоб должен быть добавлен информация, что этот джоб находится в кеше на воркере w<sub>0</sub>, то джоб должен быть добавлен
в первую локальную очередь `W0`. в первую локальную очередь w<sub>0</sub>.
Если джоб ждёт выполнения дольше `DepTimeout`, то он помещается в глобальную очередь. Если джоб ждёт выполнения дольше `DepsTimeout`, то он помещается в глобальную очередь. Отсчет этого таймаута начинается
уже после обработки предыдущего условия, то есть не нужно вычитать из `DepsTimeout` никакое другое число.
## Тестирование ## Тестирование
Вместо реального времени, юниттесты шедулера используют библиотеку `clockwork`. Это накладывает ограничения Вместо реального времени, юниттесты шедулера используют библиотеку `clockwork`. Это накладывает ограничения
на детали вашей реализации. Ожидание `CacheTimeout` и `DepTimeout` должно быть реализовано как `select {}` на на детали вашей реализации. Ожидание `CacheTimeout` и `DepTimeout` должно быть реализовано как `select {}` на
канале, который вернула функция `TimeAfter`. Мы считаем, что `CacheTimeout < DepTimeout`, и ожидание этих канале, который вернула функция `TimeAfter`. Мы считаем, что `CacheTimeout < DepsTimeout`, и ожидание этих
таймаутов происходит последовательно в одной горутине. таймаутов происходит отдельно в двух разных вызовах `select {}`:
```
select {
case <-TimeAfter(timeout):
...
...
}
```
Среди двух условий попадания во вторые локальные очереди, если выполнено первое из них, делать ожидание `CacheTimeout`
через `select {}` не нужно, иначе ваша реализация может проходить тесты с недетерминированным исходом.