Синхронизируется ли поток с предыдущим потоком с тем же идентификатором? - PullRequest
0 голосов
/ 27 мая 2019

В C ++ 11 есть std::this_thread::get_id(), который я могу использовать для получения std::thread::id идентификатора моей нити. Стандарт гласит:

30.3.1.1

  1. Объект типа thread :: id предоставляет уникальный идентификатор для каждого потока выполнения и одно отдельное значение для всех объектов потока которые не представляют поток выполнения (30.3.1). Каждая нить выполнение имеет связанный объект thread :: id, который не равен thread :: id объект любого другого потока выполнения, и это не равно объекту thread :: id любого объекта std :: thread, который не представляют потоки исполнения.
  2. thread :: id должен быть тривиально копируемым классом (раздел 9). Библиотека может повторно использовать значение thread :: id завершенного потока к которому больше нельзя присоединиться.

Мой вопрос точно касается случая, в котором новый поток B имеет тот же id, что и старый поток A: увидит ли поток B изменения, внесенные потоком A?

Чтобы быть более конкретным, рассмотрите этот сценарий:

Тема A делает:

owner.store(std::this_thread::get_id()); //store A's 'id'
...some work...
owner.store(std::thread::id(),std::memory_order_relaxed); // clear

Тема B делает:

assert(owner.load(std::memory_order_relaxed) != std::this_thread::get_id());

Будет ли это утверждение выполнено?

owner.load в теме A и последние owner.store в теме B намеренно "ослаблены", так как нет очевидной связи "между ними", кроме той, которая предполагалась в моем вопросе.

Ответы [ 2 ]

0 голосов
/ 28 мая 2019

[1] С учетом того, что написано в стандарте, и предположим, что уникальность концептуализируется с учетом физического времени, то есть в данный момент времени нет двух идентификаторов потоков, которые могут быть идентичны, тогда для обеспечения стандартного требования система должна гарантировать, что конец A происходит до начала B.

[2] Конец строки происходит после выполнения тела функции, которое было запущено в начале этого потока, и начало потока происходит до выполнения тела этой начальной функции. Как указано в [basic.exec] / 11:

При вызове функции (независимо от того, является ли функция встроенной), каждое вычисление значения и побочный эффект, связанные с любым выражением аргумента или с выражением постфикса, обозначающим вызываемую функцию, упорядочиваются перед выполнением каждого выражения или оператора в тело вызываемой функции. Для каждого вызова функции F, для каждой оценки A, которая происходит в пределах F, и каждой оценки B, которая не происходит в пределах F, но оценивается в том же потоке и как часть одного и того же обработчика сигнала (если таковой имеется), либо A последовательно перед B или B секвенируется до A.

[1] и [2] подразумевают, что каждое вычисление в потоке A происходит до любого вычисления в потоке B.

0 голосов
/ 27 мая 2019

Мой вопрос точно касается случая, в котором новая нить B имеет тот же идентификатор, что и старая нить A : увидит ли нить B изменения, внесенные нитью A?

- Таким образом, ваше условие точно соответствует сценарию, когда поток A обязательно завершается (т. Е. Больше не может быть присоединен), и поток B запущен, возможно, повторно используя поток AID.

в этом случае (потоки A и B являются последующими, а не параллельными), assert будет удерживаться - даже если его идентификатор может быть одинаковым, к моменту запуска потока B владелецхранилище будет обязательно очищено (гарантировано завершением потока A)

ОБНОВЛЕНИЕ: благодаря комментарию @Yakk - Adam Nevraumont - это был мой упуск из-за операций записи -> чтения при relaxed order- вышеприведенное утверждение неверно!т.е. фиксация памяти в последней операции потока A будет асинхронной чтению потока B, и, следовательно, утверждение может не выполняться!(извините за путаницу)

в противном случае (потоки A и B параллельны) они никогда не получат одинаковый идентификатор, и, следовательно, утверждение также будет выполняться.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...