Victor Wagner -> debian-russian@lists.debian.org @ Tue, 5 Mar 2019 07:27:45 +0300:
>> > Прикрутить туда осмысленную систему exclusive и shared блокировок >> > при условии того, что задания крутятся на куче разных машин и в >> > репозиторий ходят apt-ом весьма нетривиально. >> >> Любая система с блокировками содержит race condition :) Один мутекс >> еще нет, а любая система уже да. > Ну, слава богу, в конторе, которая занимается разработкой СУБД, люди, > способные грамотно спроектировать систему блокировок - найдутся. > > В принципе, одного мутекса НА КАЖДЫЙ РЕПОЗИТОРИЙ (например, все дебианы > это один репозиторий, все убунты - другой, а каждая астра - отдельный) > тут хватит. > Основная проблема - гарантировать то, что при любых сбоях сборочного > задания, в том числе и при ошибке установки пакетов-зависимостей, > блокировка будет снята. Собственно, не знаю, как нынче в конторах, которые занимаются разработкой СУБД, а вообще в мире параллельных выполнений нынче модно, если ресурсы позволяют (ага, это несколько дороже, чем блокировки, порой заметно дороже, зато надежнее) оптимистическая конкуренция. Это вот то, что в описанном случае выражается в виде "сделаем свою копию, эксклюзивную по построению, и потом попытаемся заменить ею оригинал". Если операция замены обломалась по причине неконсистентности, откатываем все нафиг (ну, "все", вообще говоря, контекстно, не факт, что всю сборку целиком) и повторяем заново. Обычно при реализации какая-то блокировка для момента замены (она, как водится, _почти_ атомарна) употребляется, но она уже простая, и ее можно сделать надежной. Если говорить о вышеописанной реализации, то можно сделать специально обученного демона, которому делегируется эта операция. Она простая, а запросы можно выполнять строго по очереди.
