pro.jvm

20 Jun 2025 20:25

А чаще ищут по автору или названию?

pro.jvm

20 Jun 2025 20:15

Как не получится? Получится конечно же.

pro.jvm

20 Jun 2025 20:11

Но тогда такой поиск будет неэффективным же

pro.jvm

20 Jun 2025 20:09

В плане, если у тебя индекс будет (title, author) то просто по автору не получится искать

pro.jvm

20 Jun 2025 20:08

В плане? Ну да индекс может быть из двух колонок.
Вы индекс и праймери кей не путаете?

pro.jvm

02 May 2025 10:06

Сделали ФП ЯП поверх Голанг vm, как Scala или Clojure поверх java jvm

pro.jvm

02 May 2025 09:29

?
Можно поподробнее с пояснениями, пожалуйста

pro.jvm

02 May 2025 07:01

Я как-то делал похожее на то, что тебе нужно с помощью неблокирующих очередей в комбинации с BooleanLatch. У меня было много потоков обновляющих очереди, один поток читающий в цикле эти очереди и передающий в экзекутор на исполнение. Те кто пополнял очереди, выставлял latch в позитивное значение, читающий сбрасывал его и блокировался на нем. Но забыл я почему именно этот латч выбирал, но помню, что до этого изменения очереди в цикле читались нон-стоп и подскочила утилизация цпу у одного из клиентов.

pro.jvm

01 May 2025 23:25

тут видится вопрос что хочется разгрузить, консумеров или продьюсеров. Изза этого лок можно сместить или упрятать за чек раз в N на локе как в обычном синхроне

pro.jvm

01 May 2025 23:10

перед T1 wait check c локом

pro.jvm

01 May 2025 23:08

посередеине лок на чемто

pro.jvm

01 May 2025 23:07

так он еще не замьючен

pro.jvm

01 May 2025 23:05

Так а как это спасет-то от TOCTOU? Вот он посмотрел в какой-то индикатор, индикатор ему сказал, что ничего нет, после этого он уходит в блок и ожидание сигнала. Но если сигнал пришел между проверкой индикатора и блокированием, то он потерян, и тред будет заблокирован до следующего сигнала.

pro.jvm

01 May 2025 23:01

так оно может когда угодно быть (это если вообще в очередь кто-то что-то докинет), а элемент уже доступен

pro.jvm

01 May 2025 23:00

так нет следующего полла, он висит в ожидании сигнала

pro.jvm

20 Jun 2025 20:17

Можно конечно сдвоенный индекс для запросов где оба условия

pro.jvm

20 Jun 2025 20:14

Зависит от ьипа индекса. Но все же это эффективней чем фулскан таблицы. Ну и оьычно там норм дерево собираеться

pro.jvm

20 Jun 2025 20:09

Можно конечно но это уже изменения существеное

pro.jvm

20 Jun 2025 20:08

праймери кей тоже можно композит

pro.jvm

02 May 2025 10:29

Этих новых япов куча.
Если нужна компиляция в натив и поддержка дкларативности с пайплайн программинг, то берут Rust, всё остальное не понятно для чего

pro.jvm

02 May 2025 09:57

Синтаксис очень похож на хачкель, я не спец но по мне почти один в один

pro.jvm

02 May 2025 07:35

Какой то очередной хачкель

pro.jvm

02 May 2025 06:08

Я делал так: обычная ConcurrentQueue, основной тред укладывает туда задания, другие треды (у меня было фиксированное кол-во) забирают их и исполняют. Всё просто и незатейливо. Не то?

pro.jvm

01 May 2025 23:23

Сейчас башка особо не варит, и там надо ещё посмотреть, что будут делать консюмеры, не доходящие до синхронизированной части, но с атомарными публикациями выглядит что может сработать, если паблишер всегда под тем же монитором. Про последнее я как-то не думал.

pro.jvm

01 May 2025 23:09

- T1 outstanding -> 0
- T1 tear point
- T2 publish()
- T2 outstanding <- 1
- T2 signal()
- T1 tear point recovery
- T1 wait()

pro.jvm

01 May 2025 23:08

ну смотри, у тебя ли двух этапный мьют либо двухътапный размьют

pro.jvm

01 May 2025 23:07

значит достаточно на приходе сигнала сделать доп действие чтобы размьютить второй поток

pro.jvm

01 May 2025 23:03

так если это уже не хеппи пас то там семафор или синхронайзд или дабл чек на локе объекте

pro.jvm

01 May 2025 23:01

ну так если он повис на вейте, то его разбудит следующее событие нотифая

pro.jvm

01 May 2025 23:00

- следующий пол видит волатайл
и дальше твоя логика