Блог

Каковы некоторые рекомендуемые стратегии для проверки в будущем современного кодирования на C параллельного доступа к std::shared_ptr (подобным) и std::unique_ptr (подобным) структурам данных по мере развития спецификации языка C в этой области?

Фон:

Примерно в 2021 году доступные конструкции языка C для управления доступом к std::shared_ptr (подобным) и std::unique_ptr (подобным) интеллектуальным указателям с помощью удобных для параллелизма способов находятся в процессе разработки. Например, поддержка C 20 для std::atomiclt;std::shared_ptrgt; еще не очень продвинулась в компиляторе в дикой природе, но спецификация C 20 говорит нам, что она грядет.

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

Кто-нибудь знает хорошую стратегию (возможно, хороший набор макросов CPP?) для проверки в будущем современного кода параллелизма?

[ УТОЧНЯЮЩЕЕ РЕДАКТИРОВАНИЕ после нескольких хороших комментариев (Спасибо всем) ] Из того, что я понял:

1. Разные экземпляры одного std::shared_ptr и std::unique_ptr могут быть прочитаны/записаны, из разных потоков без проблем, (например, когда разные экземпляры передаются в различные потоки), но для экземпляра объекта (или памяти), на которые они указывают, не могут быть безопасно доступны из нескольких потоков одновременно (так что вы должны использовать мьютекс, или другой способ получить доступ к заостренной к объекту, если это сценарий использования). [ Спасибо Алексу Гутеневу за эту ясность ]
2. Один и тот же экземпляр из std::shared_ptr или std::unique_ptr не может быть прочитано/записано на нити безопасным способом, используя (до c 20: std::atomic_load/store и т. д., И ПОСЛЕ С 20: std::atomiclt;std::shared_ptrgt; или std::atomiclt;std::unique_ptrgt; ) я думаю, что это может быть место, чтобы использовать cpp макросы, такие как SHARED_GET, SHARED_SET, UNIQUE_GET, UNIQUE_SET что бы централизовать изменения нужно сделать, чтобы перейти от C 17 до c 20. [ NicolBolas спасибо за ясность о том, что на самом деле в C 20. Как было указано: ссылка, которую я предоставил в комментариях ниже, устарела, поэтому будьте осторожны, чтобы не считать это фактом.]

3. Если вы не проходящий std::unique_ptr между потоками, используя std::move пройти указал в памяти, и с помощью очередей для применения, что только один поток имеет доступ в любой момент времени, вы можете использовать std_unique указатели сами и отметил в памяти в поток, который получает указатель без мьютексов и других средств защиты против ресурс утверждение.

Из-за моего замешательства при задании мой первоначальный вопрос, возможно, сбивал с толку. Теперь я бы перефразировал вопрос так: я ищу набор макросов access CPP #определяет, которые определяют C 17 и C 20 и используют самое чистое/правильное определение этой версии для следующих операций:

• MAKE_LOCAL_SHARED: Создайте/загрузите локальный экземпляр std::shared_ptr из общего/общего экземпляра, который поток может читать/записывать без разногласий с оригиналом. Он должен указывать на ту же память, на которую указывала общая/общая
• BEGIN_USE_SHARED_TGT: Создайте хранилище a std::lock_guard/mutex , в пределах которого можно безопасно использовать указанный в памяти локальный std::shared_ptr экземпляр.
• END_USE_SHARED_TGT: (возможно, просто закрывающая скобка?) Отпустите std::lock_guard/mutex , когда закончите, используя указатель на память
• BEGIN_USE_UNIQUE_TGT, END_USE_UNIQUE_TGT (то же, что и выше для std::unique_ptr

Я занимаюсь нетривиальной многопоточной разработкой, и мне нужно уметь передавать интеллектуальные указатели (как общие, так и уникальные) между потоками через (надеюсь, без блокировки) очереди и использовать их различными потокобезопасными способами.

При использовании очереди (без блокировки) вы не получаете доступ к произведенным и потребленным элементам одновременно.

Для доступа к различным переменным unique_ptr и shared_ptr уже безопасны. Когда два shared_ptr s указывают на один и тот же объект, существует гарантия того, что управление этими shared_ptr s в разных потоках является потокобезопасным, обычно реализуемым с использованием подсчета ссылок. Разные unique_ptr буквы s не указывают на один и тот же объект.

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