weak_ptr from intrusive, свой велосипед |
Здравствуйте, гость ( Вход | Регистрация )
weak_ptr from intrusive, свой велосипед |
lanz |
16.4.2015, 14:25
Сообщение
#11
|
Старейший участник Группа: Участник Сообщений: 690 Регистрация: 28.12.2012 Пользователь №: 3660 Спасибо сказали: 113 раз(а) Репутация: 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
|
Профессионал Группа: Модератор Сообщений: 1611 Регистрация: 6.2.2009 Из: Yekaterinburg Пользователь №: 533 Спасибо сказали: 219 раз(а) Репутация: 12 |
а зачем делать
если нужно делать сразу
проблема в том, что смешивать обычные указатели и shared_ptr хотя и можно чисто технически, но сильно не рекомендуется. ибо тогда вообще теряется смысл shared_ptr'а. |
|
|
alexy |
16.4.2015, 15:04
Сообщение
#13
|
Студент Группа: Участник Сообщений: 44 Регистрация: 4.8.2010 Пользователь №: 1931 Спасибо сказали: 0 раз(а) Репутация: 0 |
если нужно делать сразу
проблема в том, что смешивать обычные указатели и shared_ptr хотя и можно чисто технически, но сильно не рекомендуется. ибо тогда вообще теряется смысл shared_ptr'а. да, только при таком подходе я не смогу полчить shared_ptr в конструкторе, или у меня будут разные shared_ptr'ы тут проблема в моногопоточности. например есть какой-то поток, который генерирует очень полезные цифры. он должен показывать их на клиенте (постоянное дуплексное соединение). у него есть слабый казатель на виджет, на какой-нибудь widget::label . когда у него появляется новое число, он берет сильный указатель, проверяет не здох ли виджет (смотри ли этот пользователь или уже закрыл все и свалил) и обновляет данные. в этот момент, пока обновляет, даже если пользователь закроет, виджет никуда не денется, т.к. указатель сильный. потом сильный казатель уходит и вижет может исчезнуть за время, пока его не нужно будет обновлять. нет, дети не "владеют" родителем. они имееют слабый казатель на родителя. тут такое дело - если родителя прикончат в одном потоке, а другой поток в этот мемент работает с каким-нибудь ребенком и если ему нужно вызвать несколько методов... то у него могут прямо под носом убить объект с которым он работает и мутексы помочь не смогут, так как он берет указатель на объект и..
а weak_ptr'а нет, если иметь дело с raw pointer |
|
|
lanz |
16.4.2015, 15:15
Сообщение
#14
|
Старейший участник Группа: Участник Сообщений: 690 Регистрация: 28.12.2012 Пользователь №: 3660 Спасибо сказали: 113 раз(а) Репутация: 8 |
1. При такой архитектуре вы можете удалить виджет из другого потока, создав его в одном. Фактически его удалит тот поток, который будет держать последний shared_ptr.
2. Обновлять данные из другого потока на виджете не безопасно. Вы уверенны что не придет событие отрисовки в середине вашего обновления? Для многопоточной работы лучше исползуйте систему сообщений. Т.е. другой поток постит сообщение для отображения, а виджет смотрит - есть у него такой потомок или нет. Если нет, ничего страшного, если есть - информация безопасно обновляется. Разделяемые между потоками данные - это большая мина, с которой надо очень аккуратно обходится. |
|
|
alexy |
16.4.2015, 15:46
Сообщение
#15
|
Студент Группа: Участник Сообщений: 44 Регистрация: 4.8.2010 Пользователь №: 1931 Спасибо сказали: 0 раз(а) Репутация: 0 |
1. При такой архитектуре вы можете удалить виджет из другого потока, создав его в одном. Фактически его удалит тот поток, который будет держать последний shared_ptr. 2. Обновлять данные из другого потока на виджете не безопасно. Вы уверенны что не придет событие отрисовки в середине вашего обновления? Для многопоточной работы лучше исползуйте систему сообщений. Т.е. другой поток постит сообщение для отображения, а виджет смотрит - есть у него такой потомок или нет. Если нет, ничего страшного, если есть - информация безопасно обновляется. Разделяемые между потоками данные - это большая мина, с которой надо очень аккуратно обходится. 1. ну да.. а что в этом такого?
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 Спасибо сказали: 113 раз(а) Репутация: 8 |
Цитата 1. ну да.. а что в этом такого? Ничего, если нет несинхронизированных сторонних эффектов. Цитата 2. сам виджет thradsafe. Ну это меняет все дело Только нужно следить чтобы deadlockов не было. С очередью попроще. |
|
|
Iron Bug |
17.4.2015, 11:24
Сообщение
#17
|
Профессионал Группа: Модератор Сообщений: 1611 Регистрация: 6.2.2009 Из: Yekaterinburg Пользователь №: 533 Спасибо сказали: 219 раз(а) Репутация: 12 |
обычная схема перерисовки данных - это чтение данных по сигналу обновления виджета. поток, получающий данные, складывает их в память. а поток, который отрисовывает виджет, берёт их оттуда. и не нужно никаких сильных-слабых указателей и прочих велосипедов.
|
|
|
Текстовая версия | Сейчас: 29.3.2024, 15:08 |