Вверх ↑
Этот топик читают: Гость
Ответов: 704
Рейтинг: 7
#1: 2019-02-06 04:41:28 ЛС | профиль | цитата
Здравствуйте!
Ищу в sqlite каждую секунду значение времени (планировщик) с последующей обработкой найденного. Событий совсем не много, но если другие приложения подгрузят процессор, то обработка может занять больше интервала между поиском и следующее значение времени просто потеряется=запланированное не найдется. Пытаюсь развязать прямые запросы от MMTimer.

Как можно выкрутиться? Пробовал получение времени прятать в динамический контейнер с мьютексом внутри - помогает, но как-то нестабильно. Подкиньте свежих идей, пожалуйста.


Add(SafeMode,1103226,329,154)
{
Name="planyr1"
link(onSafeMode,15057438:doPop,[(424,160)(424,118)])
AddHint(-2,49,49,13,Name)
}
Add(Timer,3664099,189,154)
{
link(onTimer,1103226:doSafeMode,[])
}
Add(MMTimer,5142454,189,105)
{
Resolution=0
link(onTimer,14653829:doData,[])
}
Add(Message,3877249,525,112)
{
@Hint=#91:Отправляет запрос в базу со значением времени каждую секунду и после идет цепочка обработки|
AddHint(42,-43,199,39,@Hint)
}
Add(Stack,15057438,462,105)
{
link(onPop,3877249:doMessage,[])
}
Add(SafeMode,14966408,329,105)
{
Name="planyr1"
link(onSafeMode,15057438:doPush,[])
AddHint(3,-34,49,13,Name)
}
Add(Time,622046,259,63)
{
Format="h:m:s"
}
Add(DoData,14653829,259,105)
{
link(onEventData,14966408:doSafeMode,[])
link(Data,622046:FormatTime,[])
}

карма: 0

0
vip
#1.1контекстная реклама от партнеров
Ответов: 4621
Рейтинг: 746
#2: 2019-02-06 11:51:44 ЛС | профиль | цитата
Вероятно, искать надо не запись "равную текущему времени", а диапазон записей "между временем последнего поиска" и "текущим временем". Тогда конкретные значения и интервалы времени не будут иметь влияния. И не надо будет искать каждую секунду - можно и раз в 10 секунд.

Редактировалось 1 раз(а), последний 2019-02-06 11:52:30
карма: 26

0
Ответов: 704
Рейтинг: 7
#3: 2019-02-06 12:48:16 ЛС | профиль | цитата
Netspirit, спасибо! Идея упирается в знание синтаксиса, но рассматриваю. Хотя интервал нужен все же 1 сек и меньше. Есть похожая база планировщика и там события чаще встречаются, использую точность до 1/10 сек.

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

Add(Counter,11129683,210,259)
{
@Color=9371647
Max=999999999
link(onNext,4720832:doEvent1,[])
}
Add(SafeMode,11010735,322,259)
{
Name="maintime"
link(onSafeMode,4282817:doString,[])
AddHint(2,42,56,13,Name)
}
Add(Hub,4720832,266,259)
{
link(onEvent1,11010735:doSafeMode,[])
link(onEvent2,13197420:doDeferredEvent,[(305,272)(305,335)])
}
Add(Thread,7940063,154,259)
{
Delay=100
link(onExec,11129683:doNext,[])
}
Add(DeferredEvent,13197420,315,329)
{
link(onDeferredEvent,12025064:doSafeMode,[])
}
Add(SafeMode,12025064,364,329)
{
Name="maintime"
WaitMode=1
link(onSafeMode,15564026:doPop,[(515,335)(515,272)])
AddHint(-4,42,56,13,Name)
}
Add(Stack,15564026,546,259)
{
link(onPop,12013288:doWork,[])
}
Add(Message,3046473,714,266)
{
}
Add(MT_String,7923535,476,259)
{
link(onResult,15564026:doPush,[])
}
Add(FormatStr,4282817,378,259)
{
DataCount=1
Mask="SELECT * FROM tab3 WHERE time LIKE '%1';"
link(onFString,5909670:doQuery,[])
}
Add(DSC_Query,5909670,427,259)
{
DSManager="parent.mem"
link(onQuery,7923535:doStr,[])
}
Add(LineBreakEx,12013288,602,266)
{
}
Add(LineBreakEx,12118628,602,315)
{
}
Add(LineBreakEx,12057542,679,266)
{
Type=1
link(OnEvent,3046473:doMessage,[])
}
Add(LineBreakEx,9157288,602,364)
{
}
Add(LineBreakEx,13876695,602,413)
{
}


Редактировалось 2 раз(а), последний 2019-02-06 12:49:58
карма: 0

0
Разработчик
Ответов: 26066
Рейтинг: 2120
#4: 2019-02-06 12:52:59 ЛС | профиль | цитата
Neo писал(а):
LineBreakEx

Это безобразие вообще ни на что влиять не должно, тк внутри среды преобразуется в прямую связь. Оно сделано для наглядности схем, не более.
карма: 22

0
Ответов: 704
Рейтинг: 7
#5: 2019-02-06 13:18:40 ЛС | профиль | цитата
nesco, спасибо за разъяснения.
карма: 0

0
Ответов: 4621
Рейтинг: 746
#6: 2019-02-06 13:31:56 ЛС | профиль | цитата
Neo писал(а):
Хотя интервал нужен все же 1 сек и меньше
1) Грузить из БД раз в 60 секунд все записи, начиная с текущего времени по текущее + 60 сек
2) Перебирать полученные записи раз в 1 секунду и обрабатывать

Редактировалось 1 раз(а), последний 2019-02-06 13:32:13
карма: 26

0
Ответов: 704
Рейтинг: 7
#7: 2019-02-06 14:03:36 ЛС | профиль | цитата
Интересная идея! Хотя по ресурсоемкости неоднозначная. Вдруг запись будет добавлена на интервал +5 сек (такое очень часто). И здесь нужно все проверять добавлять ли в список или в базу. Больше операций с вычислением диапазона времени и сложности решения. И записи могут удаляться на ходу, меняться другими. В SQlite это побыстрее чем в списке строк искать перебором.

--- Добавлено в 2019-02-06 14:12:19

А можно выяснить состояние критической секции? Занято или свободно=накапливать в доп список (после перенести в основной) или записывать в основной список очереди. Так поток не будет ждать в случае занятости стека.

Редактировалось 2 раз(а), последний 2019-02-06 14:12:55
карма: 0

0
Ответов: 16884
Рейтинг: 1239
#8: 2019-02-06 16:34:52 ЛС | профиль | цитата
Neo писал(а):
Ищу в sqlite каждую секунду значение времени
Так и ищи в SQLite.
Следующая запись в БД

SELECT SS FROM vrem WHERE SS>time('now', 'localtime') LIMIT 1;
карма: 25
Немного терпения! Дежурный экстрасенс скоро свяжется с Вами!
0
Ответов: 704
Рейтинг: 7
#9: 2019-02-06 17:01:42 ЛС | профиль | цитата
Tad, еще не ориентируюсь, но там вроде нужен формат записи времени особый для таких финтов? И так же мне не нужно >, а нужно конкретное значение. Или это и есть ('now', 'localtime')? Но лимит в 1 не подходит - может быть не одна запись на одно время.
карма: 0

0
Ответов: 16884
Рейтинг: 1239
#10: 2019-02-06 18:23:39 ЛС | профиль | цитата
Все действия SQLite производятся в "своих личных" потоках.
Текущее локальное время time('now', 'localtime')
1. Получить и запомнить время следующего действия планировщика.
SELECT SS FROM vrem WHERE SS>time('now', 'localtime') ORDER BY SS LIMIT 1;
2. Получить список действий
SELECT * FROM vrem WHERE SS="запомненное время";

Твоя постановка задачи:

Живу в лесу. До ближайшего магазина 10 км.
Дорог нет.
Хочу использовать велосипед, а ездить на нём не умею.

Редактировалось 1 раз(а), последний 2019-02-06 22:17:37
карма: 25
Немного терпения! Дежурный экстрасенс скоро свяжется с Вами!
0
Ответов: 704
Рейтинг: 7
#11: 2019-02-06 20:37:11 ЛС | профиль | цитата
Моя постановка Вам и понята не совсем верно. Она скорее такая:

Живу возле леса. До ближайшего магазина 1 км.
Дороги зимой считай нету - это прямо в точку! Аж до слез!
Хочу трактором прочистить снежные заметы, а ездить уже велосипедом с 4 колесами, как умею. А по свободе глядишь и на трактор права получу. Он для наших дорог в самый раз сейчас.

Tad, за такой вариант спасибо! Наверное если перестраивать алгоритм, то именно на такой.

Редактировалось 3 раз(а), последний 2019-02-06 20:44:27
карма: 0

0
Ответов: 16884
Рейтинг: 1239
#12: 2019-02-07 14:31:16 ЛС | профиль | цитата
Вот. Примерно.
карма: 25
Немного терпения! Дежурный экстрасенс скоро свяжется с Вами!
0
файлы: 1Режим_шк.zip [1.5KB] [288]
Ответов: 704
Рейтинг: 7
#13: 2019-02-07 14:53:59 ЛС | профиль | цитата
Tad, это настоящая красота! Отличный пример, начал разбирать. Спасибо большое!
карма: 0

0
13
Сообщение
...
Прикрепленные файлы
(файлы не залиты)