Копирование указателя атомарно?

по идее нет

оба указателя, источник и назначение, лежат в памяти. Следим за руками

1) mov регистр, [source_ptr]
2) тут происходит прерывание, и другой поток 100500 раз меняет значения источника и назначения
3) возврат из прерывания
4) mov [dest_ptr],регистр

А в чем проблема?

>тут происходит прерывание, и другой поток 100500 раз меняет значения источника и назначения

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

Кстати, в Си/Си++ не появилось стандартного аналога synchronized { }?

неявно атомарно

В общем случае неатомарно. В сях есть только sigatomic_t, да и то вроде не на многопоточность рассчитано, не помню наверняка. В плюсы добавили <atomic>, в котором среди прочего есть и функции для указателей.

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

> можно ли такую штуковину сделать, чтобы не прерывать потоки мутексами

Можно, если писатель один. Используй atomic функции.

в моем примере я имел ввиду следующее -
source_ptr, dest_ptr - константы, содержащие адрес переменной, хранящей указатель.

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

Без разницы, если имеет место копирование из памяти в память

>source_ptr, dest_ptr - константы, содержащие адрес переменной, хранящей указатель.

И? Да угадаю, ты считаешь, что прерывания портят регистры? :)

Без разницы, если имеет место копирование из памяти в память

Это касается атомарности значения. Но не указателя.

> И? Да угадаю, ты считаешь, что прерывания портят регистры? :)

нет, не портят.

Атомарная операция - это неделимая операция.
Копирование требует двух операций - чтение из памяти, запись в память.
Между ними может произойти прерывание.
Значит - не атомарная :)

> И? Да угадаю, ты считаешь, что прерывания портят регистры? :)

Кажется, он про указатели на указатели. В данном случае ничего не отличается от присвоения аналогичных по размеру типов данных.

А, тогда еще более идиотский вопрос можно? ))
Рамер указателя - всегда равен размеру регистра процессора? На всех архитектурах?... В принципе, мне кажется, да. Но может я чего-то не знаю?
Главное, чтоб указатель по частям не переписывался )))

В принципе, вот да, не зря написал - самому яснее стало. )

> Рамер указателя - всегда равен размеру регистра процессора? На всех архитектурах?... В принципе, мне кажется, да. Но может я чего-то не знаю?

Нет, не всегда :)

Например, 32-битные длинные указатели в DOS-программах, содержащие значение сегментного регистра и смещение внутри сегмента :) а регистры были 16бит

Или контроллеры AVR - регистры по 8 бит, указатели (на код и на данные) по 16 бит

Но в современных ОС на x86 и x86_64 архитектуре длинных указателей в юзер-mode программах быть не должно, так что не парься :) На ARM вроде как тоже

Оk, спасибо!

для портируемости кода считай что в ЯВУ атомарных операций нет.

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

Это стандартный RCU трюк.

этот механизм лежит в основе транзакционной памати, если я ничего не путаю.

Копирование указателя атомарно для многих платформ в том смысле, что писатель пишет за один такт, так что читатель прочитает либо старые данные, либо новые, а при наличии одновременно двух писателей а ячейке памяти не будет половины указателя от первого писателя, а половины - от второго.

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

Теоретически можно ли такую штуковину сделать, чтобы не прерывать потоки мутексами

Можно, но Вам нужно будет скорее всего использовать специальные атомарные операции - не просто запись указателя, а compare-and-swap, атомарный инкремент и др. Откуда их взять: из APR, из gcc, из OpenPA...

Кроме того, при разработке безблокировочного алгоритма нужно иметь в виду, что другие потоки не обязаны немедленно увидеть изменённую только что ячейку памяти. Причём даже последовательность, в которой изменения становятся видимыми читателю, может отличаться от последовательности, в которой изменения записаны писателем. В тех случаях, когда этого требуется избегать, используют т.н. барьеры памяти.

Рамер указателя - всегда равен размеру регистра процессора?

Нет. В плюсах, например, размер указателя на виртуальный метод зависит от реализации. Где-то видел сравнение, на MSVS размер такого указателя достигал 20 байт :)

имхо С однопоточен по определению, by design. А многоптоковость достигается by third party libraries.

На мой взгляд вопрос в духе «можно ли управлять высотой полёта автомобиля при помощи закрылок и элеронов».

> имхо С однопоточен по определению, by design. А многоптоковость достигается by third party libraries

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

Рамер указателя - всегда равен размеру регистра процессора? На всех архитектурах?... В принципе, мне кажется, да.

нет. пример AVR, 8-и битный процессор с 16-и битными указателями.

Контроллер памяти принимает запрос на запись или чтение. Шина данных 64 бита. Если процессор выполняет одну команду записи или чтения, то она атомарна по определению, контроллер памяти не будет ничего портить, это же касается и кеша. Другой вопрос если команда сложная(xadd, xadd), тут процессору нужно сделать чтение и запись, но для таких команд есть префикс lock.

многопоточность достигается за счет операционной системы,

спасибо кэп!

а пихать в язык какую-то специальную поддержку многопоточности не нужно

ты о чём вообще?