Общее состояние: Доступ к ОДНОМУ потоку ПРОТИВ МНОГИХ потоков + Расширенное кэширование - PullRequest
Новая
       8

Общее состояние: Доступ к ОДНОМУ потоку ПРОТИВ МНОГИХ потоков + Расширенное кэширование

0 голосов
/ 20 января 2020

это продолжение этих вопросов здесь: https://groups.google.com/forum/#! Topic / vertx / MmcI2dJIcRM (мои сообщения от 08 и 20 января там)

У меня есть штат, 4 событияl oop Потоки / контексты и контекст для связывания состояний 

T state;
Context contextToStateBinder;

в веб-запросах vertx направляются циклически в разные циклы событий, поэтому 

request 1 -> eventloop A
request 2 -> eventloop B
request 3 -> eventloop C
request 4 -> eventloop D
request 5 -> eventloop A
...

, если я хочу получить доступ Исходя из этого, в запросе общего состояния у меня могут быть следующие решения:

Решение I

Доступ к состоянию разрешен только в той же теме / контексте, поэтому, возможно, я решу для contextToStateBinder -> eventl oop B context

, поэтому каждый раз, когда я хочу получить доступ к состоянию, я должен изменить событие l oop на: contextToStateBinder.runOnContext (...)

Решение II

Я должен синхронизировать состояние: синхронизирован или CAS-операция (состояние копирования, изменение состояния, запись его обратно в CAS, если успешно -> выполнено, если fail-> попробуйте еще раз)

И мой cas / synchronized или мой eventll * 10 72 * Коммутатор с runOnContext (внутренний a-mps c -queue) имеет изменчивое чтение и запись.

Итак, мой вопрос здесь: что дешевле?

Мое состояние там может быть игровой блок / чат-комната: я думаю, что лучший способ здесь - это изменить контекст и не обращаться к этому состоянию с помощью разных потоков, верно?

Мое состояние может быть состояние сеанса пользователей: здесь Джулиен (vertx-project-leader) упоминает, что это не очень хорошая идея связать пользователя с определенным контекстом (но почему?, он до сих пор не оправдал это) Может быть, это проблема, если я статически планирую разных пользователей в разных контекстах ...... так что может случиться так, что у одного события oop будет гораздо больше запросов, чем у другого. Но если я перенесу это (привязать пользователя к другим конкурсам, чтобы весь контекст имел равное количество traffi c), то я не вижу здесь никаких проблем?

Но какие еще проблемы я мог бы получить, если я это сделаю?

Почему я думаю, что это настолько мощно, привязка пользователя к определенной нити eventl oop является следующим примером:

Advanced Cache: 

user1 -> request 1 -> eventloop A -> correct to B -> start a long-database-operation -> save the future of that operation in his state -> close the connection
user1 -> request 2 -> eventloop A -> correct to B -> want-to-recieve-the-database-result -> get the future from that state -> setTheReturn-Handler -> (maybe the result isnt yet completed) -> result-handler is executed after completion -> return the result to the user1

Так что я не знаю, как я могу решить эту проблему, если я не в том же контексте / eventl oop: я думаю, если запросы 1 и 2 обращаются к состоянию и Будущее из разных потоков, тогда оно не будет работать.

Должен ли я использовать там тот же Eventl oop? Или существует какая-то другая хорошая душа, получающая доступ к будущему из разных событийных циклов?

Вы можете найти этот вопрос также на форуме vertx здесь: https://groups.google.com/forum/#! Topic / vertx / m17fwSas6_0

LG knotenpunkt

...