Сообщение Re[4]: Помогите с многопоточным кодом от 06.09.2022 12:55
Изменено 06.09.2022 13:04 vsb
Re[4]: Помогите с многопоточным кодом
Здравствуйте, maxkar, Вы писали:
M>Этот код может генерировать дубликаты в части (timeMillis, counter)
В принципе это не страшно, вторая часть заполняется случайными значениями, там совпадение практически невозможно. Но спасибо, всё же этот сценарий я хотел избежать и проглядел.
M>Чтобы поправить атомики, нужно сделать AtomicReference и объект с двумя полями — для времени и для счетчика. Вот тогда на целом объекте нужно делать Compare and Set, операция получится атомарная. Или в объекте сделать свой AtomicInt и использовать его при совпадении метки времени (для другой метки времени будет свой AtomicInteger).
AtomicReference это понятно, но это лишнее выделение объекта на каждой операции, этого хотелось избежать. С AtomicReference всё просто — через update пишешь и готово, насколько я понимаю.
M>Там слишком большой contention получается в случае continue (и особенно — переполнения счетчика). Ему бы Thread.sleep(1) вставить.
Там счётчик не переполняется по факту, по крайней мере в моих экспериментах.
В общем сделал через synchronized, мне такой скорости за глаза. Почему-то думал, что будет на порядок медленней.
Наверное можно ещё сделать через ThreadLocal переменные и не заморачиваться тем, что в разных потоках будут получаться одинаковые (timeMillis, counter), попробую ради интереса этот вариант, сравнить скорость.
M>Этот код может генерировать дубликаты в части (timeMillis, counter)
В принципе это не страшно, вторая часть заполняется случайными значениями, там совпадение практически невозможно. Но спасибо, всё же этот сценарий я хотел избежать и проглядел.
M>Чтобы поправить атомики, нужно сделать AtomicReference и объект с двумя полями — для времени и для счетчика. Вот тогда на целом объекте нужно делать Compare and Set, операция получится атомарная. Или в объекте сделать свой AtomicInt и использовать его при совпадении метки времени (для другой метки времени будет свой AtomicInteger).
AtomicReference это понятно, но это лишнее выделение объекта на каждой операции, этого хотелось избежать. С AtomicReference всё просто — через update пишешь и готово, насколько я понимаю.
M>Там слишком большой contention получается в случае continue (и особенно — переполнения счетчика). Ему бы Thread.sleep(1) вставить.
Там счётчик не переполняется по факту, по крайней мере в моих экспериментах.
В общем сделал через synchronized, мне такой скорости за глаза. Почему-то думал, что будет на порядок медленней.
Наверное можно ещё сделать через ThreadLocal переменные и не заморачиваться тем, что в разных потоках будут получаться одинаковые (timeMillis, counter), попробую ради интереса этот вариант, сравнить скорость.
Re[4]: Помогите с многопоточным кодом
Здравствуйте, maxkar, Вы писали:
M>Этот код может генерировать дубликаты в части (timeMillis, counter)
В принципе это не страшно, вторая часть заполняется случайными значениями, там совпадение практически невозможно. Но спасибо, всё же этот сценарий я хотел избежать и проглядел.
M>Чтобы поправить атомики, нужно сделать AtomicReference и объект с двумя полями — для времени и для счетчика. Вот тогда на целом объекте нужно делать Compare and Set, операция получится атомарная. Или в объекте сделать свой AtomicInt и использовать его при совпадении метки времени (для другой метки времени будет свой AtomicInteger).
AtomicReference это понятно, но это лишнее выделение объекта на каждой операции, этого хотелось избежать. С AtomicReference всё просто — через update пишешь и готово, насколько я понимаю. Хотя может тут я тоже не к месту заморачиваюсь, надо проверить для общего развития.
M>Там слишком большой contention получается в случае continue (и особенно — переполнения счетчика). Ему бы Thread.sleep(1) вставить.
Там счётчик не переполняется по факту, по крайней мере в моих экспериментах.
В общем сделал через synchronized, мне такой скорости за глаза. Почему-то думал, что будет на порядок медленней.
Наверное можно ещё сделать через ThreadLocal переменные и не заморачиваться тем, что в разных потоках будут получаться одинаковые (timeMillis, counter), попробую ради интереса этот вариант, сравнить скорость.
M>Этот код может генерировать дубликаты в части (timeMillis, counter)
В принципе это не страшно, вторая часть заполняется случайными значениями, там совпадение практически невозможно. Но спасибо, всё же этот сценарий я хотел избежать и проглядел.
M>Чтобы поправить атомики, нужно сделать AtomicReference и объект с двумя полями — для времени и для счетчика. Вот тогда на целом объекте нужно делать Compare and Set, операция получится атомарная. Или в объекте сделать свой AtomicInt и использовать его при совпадении метки времени (для другой метки времени будет свой AtomicInteger).
AtomicReference это понятно, но это лишнее выделение объекта на каждой операции, этого хотелось избежать. С AtomicReference всё просто — через update пишешь и готово, насколько я понимаю. Хотя может тут я тоже не к месту заморачиваюсь, надо проверить для общего развития.
M>Там слишком большой contention получается в случае continue (и особенно — переполнения счетчика). Ему бы Thread.sleep(1) вставить.
Там счётчик не переполняется по факту, по крайней мере в моих экспериментах.
В общем сделал через synchronized, мне такой скорости за глаза. Почему-то думал, что будет на порядок медленней.
Наверное можно ещё сделать через ThreadLocal переменные и не заморачиваться тем, что в разных потоках будут получаться одинаковые (timeMillis, counter), попробую ради интереса этот вариант, сравнить скорость.