Size: a a a

2020 September 21

VF

Vitaly Farmov in pro.cxx
?
источник

VF

Vitaly Farmov in pro.cxx
voodoo
1.  может кто пояснить по либе Poco:
Poco::Event CustomTask::_custom_event;
void CustomTask::runTask()
{  
   while (!isCancelled())
   {
       if(_custom_event.tryWait(400))
       {
           ...
       }
   }
}
какой сакральный смысл в tryWait ?

2. задача - обновлять массив, к которому идут обращения в реалтайме.
устанавливается флаг isUpdate и проверяется при каждой попытке чтения , т.е. если флаг true, то получаем безопасное обновление, но недоступность информации на несколько секунд
есть ли способы сделать обновление без лишней проверки, безопасно и с минимумом простоя?
Немного неясно из вашей постановки задачи, какая сторона обновляет массив?
источник

v

voodoo in pro.cxx
а можно для индейцев пояснить, allows users to manipulate shared_ptr objects atomically
если в момент чтения я сменю указатель, ну или сделаю clear() будет ведь либо краш либо левые данные?
источник

v

voodoo in pro.cxx
извне посылается команда Poco приложению, запускается таска и обновляет массив, а приложение серверное работает постоянно
источник

DS

Dmitry Sokolov in pro.cxx
Аа, pardon. Все норм только если все с ним работают через atomic.
источник

v

voodoo in pro.cxx
я вот переживаю как избежать краша и до последнего сделать доступными старые данные
источник

VF

Vitaly Farmov in pro.cxx
voodoo
извне посылается команда Poco приложению, запускается таска и обновляет массив, а приложение серверное работает постоянно
Так пусть она просто атомарно обновит шаред пойнтер, как предложил Дмитрий? Либо под мьютексом делайте мув нового массива
источник

v

voodoo in pro.cxx
ох, ещё б понять о чём речь)) пойду курить shared_ptr и mutex
всех благодарствую за помощь
источник

VF

Vitaly Farmov in pro.cxx
voodoo
ох, ещё б понять о чём речь)) пойду курить shared_ptr и mutex
всех благодарствую за помощь
Ну я бы не делал атомарный шаред пойнтер, потому что чтение данных потом все-равно под мьютексом надо будет делать
источник

ПК

Побитый Кирпич... in pro.cxx
Vitaly Farmov
Ну я бы не делал атомарный шаред пойнтер, потому что чтение данных потом все-равно под мьютексом надо будет делать
Если двойная буферизация, то нет
источник

ПК

Побитый Кирпич... in pro.cxx
Из одного буфера только чтение
источник

ПК

Побитый Кирпич... in pro.cxx
Другой вопрос что там и обычного указателя достаточно
источник

ПК

Побитый Кирпич... in pro.cxx
И просто его свапать атомарно
источник

AF

Aidar Fattakhov in pro.cxx
Побитый Кирпич
Если двойная буферизация, то нет
Походу тройная + майлбокс
источник

DS

Dmitry Sokolov in pro.cxx
voodoo
ох, ещё б понять о чём речь)) пойду курить shared_ptr и mutex
всех благодарствую за помощь
Я сделал common TLS registry, туда накидываю индекс TLS pub, интерфейсы pub данных. В TLS потока в списке кладу TLS sub. По команде обновления всё синхронизирую. Тупо, просто, дёшево.
источник

VF

Vitaly Farmov in pro.cxx
Побитый Кирпич
И просто его свапать атомарно
В какой момент?
источник

DS

Dmitry Sokolov in pro.cxx
Vitaly Farmov
Ну я бы не делал атомарный шаред пойнтер, потому что чтение данных потом все-равно под мьютексом надо будет делать
Если это immutable cow, зачем мьютексы?
источник

P

PRoSToC0der in pro.cxx
Андрей Руссков
кажется, возвращать std::function чуть лучше, чем структуру с указателем на callback, void* контекстом и указателем на функцию удаления контекста
иногда ты не можешь опираться на плюсовое ABI, например, когда пишешь dll-плагин к какой-то готовой системе (и соответственно линкуешь стандартную библиотеку статически)
источник
2020 September 22

v

voodoo in pro.cxx
в общем как я понял, без лишней операции не обойтись никак
по моему проверять свой флаг дешевле, чем
read_lock(&listmutex);  
...
read_unlock(&listmutex);
источник

AF

Aidar Fattakhov in pro.cxx
источник