Replies (15)

  • @qnikst, Напоминает журнал транзакций.
  • @zoonman, скорее paxos, raft и вот это все, только упрощенно (и похоже неправильно)
  • @qnikst, а где там race?
  • @qnikst, нет, но непонятно зачем там вообще лок, при единственном ресурсе, который, как видно, сам может разрулить гонки при обращении к себе самому. Видимо, там какаято бОльшая схема нужна
  • @blaze, если write после gc успевает отправиться до write из получившего лидерство
  • @qnikst, это нормально, последовательность же сохранена, вперемешку никто не писал.
  • @max630, эм.. то, что ресурс может разрулить гонки тут это какая-то совсем новая для меня инфа тут. как?
  • @blaze, у тебя в один момент получается, один период есть 2 лидера. это сработает только если , если результат write(token=33)>>write(token=34) = write(token=34).
  • @qnikst, это сработает если токен управляет только записью в базу и больше ничем. В остальных случаях не сработает, но кажется тут этого и не хотят.
  • @qnikst, ну когда к нему условно одновременно ломятся Client 1 с 33 и Client 2 с 34, он как-то умудряется гарантированно принять либо c1+c2, либо c2 и послать c1. Если он такой умный, зачем вообще лок?
  • @max630, в смысле "как-то"? Тупо по номерам.
  • @max630, ну почему умный? один поток обрабатывающий входящие команды, с цифровым токеном, при этом выкидывающий номера меньше, чем тот, который он видел. Вроде достаточно просто..
    А лок нужен для того, чтобы нумера эти были хорошо распределены и у двух потоков не было одинакового.
  • @blaze, ясно
  • @qnikst, а зачем вообще эти номера? что они обеспечивают? что сломается от того что client 1 придёт в него после client 2? а если client 1 заснёт до обращения в лок, он таки придёт позже и это будет корректно. Почему тогда просто не выписывать номера на стораже?
  • @max630, на самом деле из предположений /9 я ответить не могу. А если лок и для чтения и записи и он гарантирует эксклюзивный доступ к ресурсу(ам), то тогда там есть race