Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.137.157.45] |
|
Страницы: (16) 1 [2] 3 4 ... 15 16 все ( Перейти к последнему сообщению ) |
Сообщ.
#16
,
|
|
|
Собственно причин, почему этот код не должен работать я не вижу. С моими классами вроде работает
Добавлено Кроме того в Microsoft c++ тоже должен работать, но тут врать не буду, не проверял |
Сообщ.
#17
,
|
|
|
Код не смотрел, но я против! Шютка... Но в каждой шутке - есть доля шутки. Самый главный вопрос можно сформулировать пока двумя тезисами: 1) Многопоточное приложение наибоее эффективно, если его потоки не простаивают 2) Многопоточное приложение наибоее эффективно, если его потоки тратят на синхронизацию минимум рабочего времени Хотя первый тезис - сиречь, в постановке вопроса данного топика, можно опустить. Т.к., имея "низкоуровневый" механизм обеспечения многопоточности - мы его ну просто обязаны пользовать на право и на лево. А это лютые, бешеные "тонны" синхронизации! Конечно, возникнет, "практически законный" вопрос, типа а если очень надо? Ответ есть: нужно пользовать механизмы обеспечения "параллелизма" более высокого порядка. Пока расписывать не буду. Соберусь с мыслями и забабахаю тему-конкурс. А пока ... типа "напочитать" тема - тут (если быть точнее 15.2.1). Дело понятное, мой ответ в стиле "имхо" - ошибаться право имею! |
Сообщ.
#18
,
|
|
|
Выяснилось, что эти мои SharedPtr/WeakPtr не работают. Где-то есть косяк. Понять бы где
|
Сообщ.
#19
,
|
|
|
Олег М, почему бы потокам не иметь свои собственные экземпляры указателей? Тогда можно обойтись стандартными средствами, а не делать свои велосипеды.
|
Сообщ.
#20
,
|
|
|
В смысле копировать указатели только в одном потоке и передавать их в другие, я правильно понял? Да так можно решить некоторые задачи, но далеко не все. Либо реализация такой схемы будет слишком дорогой. В общем случае ты вообще ничего не знаешь в каком потоке указатель был создан и в каком и когда будет удален.
|
Сообщ.
#21
,
|
|
|
Цитата Олег М @ Собственно причин, почему этот код не должен работать я не вижу. Всё очень просто. Есть объект, на который указывает умный указатель. А есть умный указатель, который указывает на объект. Так вот, объект (указываемый) должен быть один. А вот копий указателей на него - много. Щёлкать ссылками на указываемый объект из разных потоков - не проблема. Это прекрасно можно. Но вот работать из разных потоков с одним экземпляром указывающего объекта (умного указателя) - нельзя. Нужно снять с него копию, передать в другой поток и с этой копией в том потоке работать. Твой же код в нескольких потоках работает именно с одной копией умного указателя (а не указываемого объекта), что прямо запрещено стандартом. |
Сообщ.
#22
,
|
|
|
Вот операция "снять копию" и должна быть потоко–безопасной. И в стандарте вроде написано, что это запланировано на будущее. Это раз. А во вторых – ну снимешь ты копию weak_ptr, ну передашь ее в другой поток, и что? Как ты из него shared-ptr планируешь создавать, возвращаться в первый поток?
|
Сообщ.
#23
,
|
|
|
Цитата Олег М @ Вот операция "снять копию" и должна быть потоко–безопасной. Не должна. Судя по всему, ты как-то странно предполагаешь shared pointer'ы использовать. Традиционный подход такой: сколько точек "хранения" указателя - столько копий shared_ptr'а. И таково значение счётчика ссылок. Когда последнему пользователю указателя объект перестаёт быть нужным - удаляется последняя копия shared_ptr'а и объект разрушается. Создать указываемый объект в одном потоке и передать его в другой, просто расшарив между потоками одну копию shared_ptr'а? Это что-то оригинальное. Тут явная синхронизация нужна, потому что контейнер (shared_ptr) становится разделяемым ресурсом. Есть, впрочем, ещё один вариант - использовать future's и std::async. Ну, это если по-правильному. |
Сообщ.
#24
,
|
|
|
Ты забываешь про weakptr. Это во первых. Во вторых, когда ты создаешь копию shardptr, ты по сути блокируешь ресурс от удаления. Сам бог велел использовать это свойство для синхронизации доступа к ресурсу.
|
Сообщ.
#25
,
|
|
|
Цитата Олег М @ В смысле копировать указатели только в одном потоке и передавать их в другие, я правильно понял? ... Либо реализация такой схемы будет слишком дорогой. В общем случае ты вообще ничего не знаешь в каком потоке указатель был создан и в каком и когда будет удален. Даже не знаю. Просто для интереса - я попробовал оба варианта. С обычными указателями получилось даже проще. Было так: 1. Некий поток получает данные. 2. Получим память для них, если нет свободного реcурса в обратной очереди. 3. указатель - в очередь. Потокобезопасную. При закрытии приложения, все данные, чей указатель в очереди, ликвидирует сама очередь. 4. Посылаем уведомление "данные получены" 5. Другой поток получае уведомление. 6. Получает указатель на данные из очереди. 7. Строит графики в памяти. 8. Если данные не нужны, - указатель в обратную очередь. С построенными графиками - то-же самое. Только их указатели отправлябтся очередью главному потоку. Таким образом, получили полностю асинхронную схему обработки данных - никто никого никогда не ждёт. Можно использовать очередь обычных указателей, можно SP. С обычными по-проще будет. |
Сообщ.
#26
,
|
|
|
Цитата Олег М @ Ты забываешь про weakptr. Это во первых. Во вторых, когда ты создаешь копию shardptr, ты по сути блокируешь ресурс от удаления. Сам бог велел использовать это свойство для синхронизации доступа к ресурсу. Блокировать ресурс от удаления - это не синхронизировать многопоточный доступ к ресурсу. Это совершенно разные вещи. weak_ptr нужен для того, чтобы не держать взаимные ссылки объектов друг на друга (буде такое случиться). Синхронизацию на модифицирующий доступ к shared_ptr это всё равно не отменяет. |
Сообщ.
#27
,
|
|
|
Ладно. Перефразирую вопрос –нужен потоко–безопасный sharerptr. Как его реализовать, конструктор копирования, reset и weakptr;;lock?
|
Сообщ.
#28
,
|
|
|
Ну так что, никто не попытается решить задачу? Хотя бы так, для общего развития? А то, судя по написанному, совсем плохая картина, в области многопоточного программирования.
|
Сообщ.
#29
,
|
|
|
Олег М, дабы избежать проблемы XY, давай начнём с другого: для решения какой задачи тебе нужен потоко-безопасный смарт-поинтер?
|
Сообщ.
#30
,
|
|
|
Для решения довольно широкого круга задач. Да, их можно решить другими способами, как и любую задачу, но, проще и дешевле – при помощи shsredptr. Однако для этого требуется чтобы тот был потоко–безопасным.
Чтобы решить эту проблему не обязательно выясгять, что я буду потом делать с этим указателем. Есть код и нужно просто прочитать его и сказать – работает он или нет и почему. Добавлено По поводу XY – на мой взгляд основная проблема в том, что я спрашиваю об одном, а мне пытаются читать лекции совершенно о другом. Насколько я понял всх тут смутило слово sharedptr – мозг тут же отключается от задачи, дальше можно не читать и т.д. Ну, давайте я назову класс как–нибудь по другому – TreadSafePtr, например или как угодно. Тогда может ктонибудь удосужится посмотреть код? |