C99: Ограниченные указатели на безопасность потоков документации?

Этот вопрос не о техническом использовании ограниченного, а больше о субъективном использовании. Хотя я могу ошибаться относительно того, как работает ограничение с технической точки зрения, в этом случае вы можете смело обвинять меня в том, что я поставил вопрос на ложной предпосылке.

Вот два примера того, как я использую ограниченное до сих пор:

Если у меня есть функция, которая принимает указатель на последовательность неизменяемых символов, я не говорю, что она ограничена, поскольку другим людям разрешен доступ к данным через свои собственные указатели одновременно с выполнением функции, например из другого параллельного потока. Данные не изменяются, так что нет проблем.

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

Я не кодирую много C, поэтому я мог легко ошибаюсь в том, что я здесь предполагаю. Это правильное использование restrict? Стоит ли это делать в этом сценарии?

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

Правильно ли я все понял?

РЕДАКТИРОВАТЬ:

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

Но учитывая что любой контекст, в котором аргумент может быть изменен через ссылку, ясно, что к нему нельзя обращаться во время выполнения функции. Это ничего не делает для обеспечения безопасности потоков , но четко документирует, что вы изменяете данные с помощью собственного указателя во время выполнения функции на свой страх и риск .

Даже если многопоточность полностью исключена из уравнения, вы все равно допускаете дальнейшую оптимизацию в сценарии, который мне кажется правильным.

Тем не менее, спасибо за все ваши авторитетные ответы. Проголосовать ли я за все ответы, которые мне понравились, или только за тот, который я принимаю? Что, если будет принято более одного? Извините, я здесь новенький, сейчас посмотрю подробнее ...