crossplatform.ru

Здравствуйте, гость ( Вход | Регистрация )

2 страниц V  < 1 2  
Ответить в данную темуНачать новую тему
> weak_ptr from intrusive, свой велосипед
lanz
  опции профиля:
сообщение 16.4.2015, 14:25
Сообщение #11


Старейший участник
****

Группа: Участник
Сообщений: 690
Регистрация: 28.12.2012
Пользователь №: 3660

Спасибо сказали: 108 раз(а)




Репутация:   8  


shared_ptr подразумевает некую семантику - когда shared_ptr является членом класса, это значит что класс совместно владеет этим объектом вместе с кем-то. Когда у вас указатель parent shared_ptr, значит потомок владеет своим родителем.
Вот если родитель владеет(shared_ptr а то и unique_ptr) своим потомком, а потомок ссылается (raw pointer) на своего родителя, то нет никаких противоречий.
Единственное чтобы время жизни родителя перекрывало время жизни ребенка.

Цитата
ну, я ввел понятие токена. сессия без логина, не принимает никаких параметоров, сессия с логином, принимает строку токена, ну и не создается (throw login_error) если токен не верен.

В случае исключения никогда не вызовется деструктор сессии.




И насчет возврата из фабрики
http://herbsutter.com/2013/05/30/gotw-90-solution-factories/

Сообщение отредактировал lanz - 16.4.2015, 14:10
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Iron Bug
  опции профиля:
сообщение 16.4.2015, 14:29
Сообщение #12


Профессионал
*****

Группа: Модератор
Сообщений: 1566
Регистрация: 6.2.2009
Из: Yekaterinburg
Пользователь №: 533

Спасибо сказали: 211 раз(а)




Репутация:   12  


а зачем делать
auto sptr_ = new foo();
std::shared_ptr<foo> sptr = sptr_->get_shared();


если нужно делать сразу
std::shared_ptr<foo> sptr = shared_ptr<foo>(new foo());


проблема в том, что смешивать обычные указатели и shared_ptr хотя и можно чисто технически, но сильно не рекомендуется. ибо тогда вообще теряется смысл shared_ptr'а.
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
alexy
  опции профиля:
сообщение 16.4.2015, 15:04
Сообщение #13


Студент
*

Группа: Участник
Сообщений: 44
Регистрация: 4.8.2010
Пользователь №: 1931

Спасибо сказали: 0 раз(а)




Репутация:   0  


Цитата(Iron Bug @ 16.4.2015, 15:29) *
если нужно делать сразу
std::shared_ptr<foo> sptr = shared_ptr<foo>(new foo());


проблема в том, что смешивать обычные указатели и shared_ptr хотя и можно чисто технически, но сильно не рекомендуется. ибо тогда вообще теряется смысл shared_ptr'а.


да, только при таком подходе я не смогу полчить shared_ptr в конструкторе, или у меня будут разные shared_ptr


тут проблема в моногопоточности.
например есть какой-то поток, который генерирует очень полезные цифры. он должен показывать их на клиенте (постоянное дуплексное соединение). у него есть слабый казатель на виджет, на какой-нибудь widget::label . когда у него появляется новое число, он берет сильный указатель, проверяет не здох ли виджет (смотри ли этот пользователь или уже закрыл все и свалил) и обновляет данные. в этот момент, пока обновляет, даже если пользователь закроет, виджет никуда не денется, т.к. указатель сильный. потом сильный казатель уходит и вижет может исчезнуть за время, пока его не нужно будет обновлять.

нет, дети не "владеют" родителем. они имееют слабый казатель на родителя. тут такое дело - если родителя прикончат в одном потоке, а другой поток в этот мемент работает с каким-нибудь ребенком и если ему нужно вызвать несколько методов... то у него могут прямо под носом убить объект с которым он работает и мутексы помочь не смогут, так как он берет указатель на объект и..
// плохо, если some_spin - raw pointer
int val = some_spin->value();
// тут другой поток убивает родителя...
if(!do_somthis(val)) some_spin->value(0);

а weak_ptr'а нет, если иметь дело с raw pointer
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
lanz
  опции профиля:
сообщение 16.4.2015, 15:15
Сообщение #14


Старейший участник
****

Группа: Участник
Сообщений: 690
Регистрация: 28.12.2012
Пользователь №: 3660

Спасибо сказали: 108 раз(а)




Репутация:   8  


1. При такой архитектуре вы можете удалить виджет из другого потока, создав его в одном. Фактически его удалит тот поток, который будет держать последний shared_ptr.

2. Обновлять данные из другого потока на виджете не безопасно. Вы уверенны что не придет событие отрисовки в середине вашего обновления?

Для многопоточной работы лучше исползуйте систему сообщений. Т.е. другой поток постит сообщение для отображения, а виджет смотрит - есть у него такой потомок или нет. Если нет, ничего страшного, если есть - информация безопасно обновляется. Разделяемые между потоками данные - это большая мина, с которой надо очень аккуратно обходится.
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
alexy
  опции профиля:
сообщение 16.4.2015, 15:46
Сообщение #15


Студент
*

Группа: Участник
Сообщений: 44
Регистрация: 4.8.2010
Пользователь №: 1931

Спасибо сказали: 0 раз(а)




Репутация:   0  


Цитата(lanz @ 16.4.2015, 16:15) *
1. При такой архитектуре вы можете удалить виджет из другого потока, создав его в одном. Фактически его удалит тот поток, который будет держать последний shared_ptr.

2. Обновлять данные из другого потока на виджете не безопасно. Вы уверенны что не придет событие отрисовки в середине вашего обновления?

Для многопоточной работы лучше исползуйте систему сообщений. Т.е. другой поток постит сообщение для отображения, а виджет смотрит - есть у него такой потомок или нет. Если нет, ничего страшного, если есть - информация безопасно обновляется. Разделяемые между потоками данные - это большая мина, с которой надо очень аккуратно обходится.


1. ну да.. а что в этом такого?
#include <thread>
int main() {
    int * i = new int(0);
    std::thread th([i](){delete i;});
    th.join();
}


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

мне кажется с очередью сообщений труднее. сейчас у меня виджет содержит данные и мутекс, также функционал от widget_base - слабый казатель на родителя, который и так thread_safe
сообщения они передают клиенту по thradsafe каналу, то есть там мутекс перед тем как оправить данные, так что пользователю каша не придет.


кстати, не понял что-то функционала boost::intrusive_ptr если в конструкторе ему передать (some_raw_pointer, false). это же вызовет ошибку в деструкторе его. или intrusive_ptr_release нужно делать if(counter && --counter == 0) delete p;
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
lanz
  опции профиля:
сообщение 16.4.2015, 18:17
Сообщение #16


Старейший участник
****

Группа: Участник
Сообщений: 690
Регистрация: 28.12.2012
Пользователь №: 3660

Спасибо сказали: 108 раз(а)




Репутация:   8  


Цитата
1. ну да.. а что в этом такого?

Ничего, если нет несинхронизированных сторонних эффектов.
Цитата
2. сам виджет thradsafe.

Ну это меняет все дело :lol:
Только нужно следить чтобы deadlockов не было. С очередью попроще.
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Iron Bug
  опции профиля:
сообщение 17.4.2015, 11:24
Сообщение #17


Профессионал
*****

Группа: Модератор
Сообщений: 1566
Регистрация: 6.2.2009
Из: Yekaterinburg
Пользователь №: 533

Спасибо сказали: 211 раз(а)




Репутация:   12  


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

2 страниц V  < 1 2
Быстрый ответОтветить в данную темуНачать новую тему
Теги
Нет тегов для показа


1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0




RSS Текстовая версия Сейчас: 19.6.2018, 19:28