Вопрос Можно ли забить на потокобезопасность?

[whylovv]

Я написал своё API для меню. Проблема в том, что если я обновляю меню (устанавливаю title через view, предметы) в Async потоке, нагрузки вообще 0. Но если в основном - нагрузка появляется. Как в итоге лучше поступить? Забить или всё таки вызывать в синхронном потоке?

 

[Enwulf]

Забить или всё таки вызывать в синхронном потоке?

Не забивать: асинхронно - только логика и подготовка данных, любые операции с меню/инвентарем - в основном потоке

 

[NoooobKa]

Делай в другом потоке до того момента пока не встретишь причину делать синхронно

 

[Overwrite]

Делай в другом потоке до того момента пока не встретишь причину делать синхронно

offtop

Я думаю он очень быстро найдёт такую причину
В виде дюпов

 

[NoooobKa]

offtop

Я думаю он очень быстро найдёт такую причину
В виде дюпов

Этож меню, там клики должны отменятся в подавляющем кол-ве случаев

 

[HomaPlus]

Я написал своё API для меню. Проблема в том, что если я обновляю меню (устанавливаю title через view, предметы) в Async потоке, нагрузки вообще 0. Но если в основном - нагрузка появляется. Как в итоге лучше поступить? Забить или всё таки вызывать в синхронном потоке?

offtop

Такой вот нескромный вопрос - этож насколько нужно было наговнокодить чтобы чертово меню вызывало лаги?

 

[whylovv]

offtop

Такой вот нескромный вопрос - этож насколько нужно было наговнокодить чтобы чертово меню вызывало лаги?

я как понимаю когда у тебя на аукционе 5к лотов и ты его постоянно листаешь, обновляешь у тебя оно нагружает на 0.01?

 

[HomaPlus]

я как понимаю когда у тебя на аукционе 5к лотов и ты его постоянно листаешь, обновляешь у тебя оно нагружает на 0.01?

Если выложишь исходники на github могу глянуть причину лагов

Конкретно аукционов не делал да и оно мне не надо - у меня были другие смежные задачи

0.7 секунды мне было достаточно чтобы

1. Просканировать БД (150к строк) (Структура - БД - числовой ID - ключ, строка - значение)
2. Просканировать длинный json (50мб)
3. Создать новую БД (150к) и правильно слить ранее прочитанные данные (либо по числовому ID, либо по строковому значению)

Но и писал на гошке - на яве нужно в 3 раза больше времени

 

[NoooobKa]

я как понимаю когда у тебя на аукционе 5к лотов и ты его постоянно листаешь, обновляешь у тебя оно нагружает на 0.01?

Вся обработка лотов должна быть асинхронной. inv.setitem сам по себе почти не жрет, но если не будешь блокировать(временно, например на 0.3с) клики вызывающие логику (например переход на следующую страницу), то это станет дыркой, игроки просто смогут спамить этим, тем самым засноуболить нагрузку.
Вобщем делай примерно так click(Main thread) -> lock clicks(Main thread) -> handle lots (async) -> setItems/settitle(async) -> unlock clicks после выполнения всего кода + делей анлока по необходимостию При таком подходе тайминги будут показывать 0.00 нагрузки в главном потоке при любом кол-ве лотов

 

[whylovv]

Вся обработка лотов должна быть асинхронной. inv.setitem сам по себе почти не жрет, но если не будешь блокировать(временно, например на 0.3с) клики вызывающие логику (например переход на следующую страницу), то это станет дыркой, игроки просто смогут спамить этим, тем самым засноуболить нагрузку.
Вобщем делай примерно так click(Main thread) -> lock clicks(Main thread) -> handle lots (async) -> setItems/settitle(async) -> unlock clicks после выполнения всего кода + делей анлока по необходимостию При таком подходе тайминги будут показывать 0.00 нагрузки в главном потоке при любом кол-ве лотов

когда мои шаги были такие: event.setCancelled(sync) -> подготовка + установка(async), не жрало вообще ничего.
саму обработку кликов я делал по ситуации, иногда когда например сортировал лоты, то вызывал в async. если же просто в объекте страницу поменять, то в main, но лоты всё равно всегда ставятся в async.