Без блокировки только с 8-байтовым CAS? C ++

Question

Без блокировки только с 8-байтовым CAS? C ++

0

Я использую 64-разрядную систему x86, ограниченную максимум 8 байтами для операций сравнения и свопинга. Поскольку указатели являются 8-байтами, и мне нужен счетчик, чтобы избежать проблемы с ABA, возможно ли изменить верхние 16 бит указателя, которые не используются для хранения счетчика?

pointer_as_dec = reinterpret_cast<uintptr_t>(&node); // Node address
pointer_as_dec+(1LLU<<48); // Initialize the counter in one of the upper bits

Можно ли использовать функцию __sync_bool_compare_and_swap для хранения измененного адреса указателя?

user3217789 22 янв. 2014, в 05:34

Источник

Теги:

c++

c

c++11

atomic

thread-safety

1 ответ

Ещё вопросы

abarnert · Accepted Answer · 2014-01-22T01-53-00.000Z

Ну, это не гарантируется работать в соответствии с любым стандартом - единственное, что вам действительно разрешено делать с приведением указателя в int, - это вернуть его обратно в указатель без изменений. Но практически он будет работать на любой платформе x86_64 и практически любой другой текущей платформе. И, очевидно, вы не ожидали, что gcc-специфичный, x86_64-специфичный код будет переносимым. Итак, здесь нет проблем.

Кроме того, uintptr_t не является одним из поддерживаемых типов для gcc-функций, но он полностью совместим с unsigned long long int. (Если вы беспокоитесь об этом, вы всегда можете добавить второй бросок...) Таким образом, здесь нет проблем.

Между тем, __sync_bool_compare_and_swap не заботится о том, чтобы вы контрабандировали указатель в этом uintptr_t; насколько это касается, это просто неподписанное 64-битное целое число. Итак, здесь нет проблем.

Вы действительно можете быть уверены, что первые 16 бит всегда пусты? В x86_64 linux они предназначены для вашей обычной пользовательской памяти. Возможно, они не предназначены для указателей на память ядра или аппаратное обеспечение с отображением памяти, и они могут быть не в других системах x86_64, но в противном случае они будут всего 1 с. И, как указывает Брендан, это гарантируется для всего, что работает на оборудовании x86_64 без 128-разрядного CAS. * Итак, если вам нужно указать на такую память или порт на такие системы, просто используйте 15 бит вместо 16. (И даже если это были неверны, предполагая, что вы указываете, скажем, на объекты с 64-битным выравниванием, у вас также есть 6 свободных бит на другом конце указателя, которые вы могли бы использовать вместо этого.) Таким образом, нет проблема здесь тоже.

* За исключением маловероятного события, которое AMD или Intel или кто-то другой решает изменить размер виртуального адреса, а также решает отнять 128-битный CAS...

Спасибо за ваш ответ, это полезно. Поскольку _sync_bool_cas принимает указатель на ячейку памяти в качестве первого аргумента, как бы я передавал число, хранящееся в uintptr_t (точнее, в uint64_t после того, как я это произвел), а не указатель на саму переменную uintptr_t?
@ user3217789: Вы не можете использовать munged-up-disguised-pointer в uintptr_t в качестве указателя , вы можете использовать его только в качестве значения . Независимо от структуры у вас есть , что ссылки какой - то объект , который должен быть CAS'd, вы храните потеряются указатели там, вместо реальных указателей. Затем вы CAS их, используя адрес прямо в структуре. И вы должны снять кусочки, чтобы разорвать их.
@ user3217789: И подумай, что хорошего в том, чтобы иметь счетчик на самом указателе? Весь смысл CAS состоит в том, чтобы убедиться, что 64-битная память, на которую указывают, не изменилась с момента последней проверки. Никого не волнует, есть ли у вас новый указатель на эти 64 бита памяти, только то, что там. И помните, что прежде всего вам нужен CAS, потому что другие объекты будут иметь другие указатели на тот же адрес.
Вы можете быть уверены, что, если указатель действителен, верхние 16-разрядные числа являются либо всеми нулями, либо полностью установленными, поскольку действительный (канонический) виртуальный адрес фактически является 48-разрядным и "расширенный знак" до 64-разрядного. По крайней мере, теоретически, в конечном итоге Intel или AMD могут добавить другой способ подкачки в длинном режиме и увеличить размер виртуального адресного пространства (но это произойдет не скоро, и 128-битный CAS уже существует). Также может быть несколько «всегда нулевых из-за выравнивания» наименее значимых битов, если вы в отчаянии.
@ Брендан: Почти все это уже было в ответе. Но спасибо за указание, что all-0s-or-all-1s гарантирован на любой платформе x86_64 без 128-битного CAS; добавил это к тексту.
« uintptr_t не является одним из поддерживаемых типов», что вы подразумеваете под этим? Это только typedef обязательно указывающий на один из базовых типов, которые должны охватываться этим.
@JensGustedt: Ни C, ни POSIX не требуют, чтобы эти определения типов соответствовали каким-либо конкретным стандартным типам в любом месте, просто они соответствуют некоторому встроенному интегральному типу правильной ширины. Смотрите POSIX <stdint.h> для примера.
@abarnert, неправильно. C определяет, что это «целочисленный тип без знака», и четко определяет, что это может быть. В частности, это не может быть какой-то произвольный «встроенный интегральный тип». Расширенный целочисленный тип может быть определен некоторыми платформами, но я не знаю ни одной, которая имеет их.
@JensGustedt: Да, это целое число без знака типа. Это не определенный тип целого числа без знака. На самом деле, 7.18 явно говорит: «Некоторые из этих типов могут обозначать определяемые реализацией расширенные целочисленные типы». Таким образом, вы не можете сказать, что C гарантирует, что это будет то же самое, что и unsigned long long (даже игнорируя тот факт, что C не требует, чтобы какой-либо из этих типов был точно 64-битным ...). Однако 6.2.5 и 6.2.6.2 гарантируют, что значения будут иметь одинаковые представления. Поэтому, как я уже сказал в ответе, все еще безопасно для использования.
@JensGustedt: (Так как мы разбираемся в технике, я использую 64-битный как ярлык для «с 64 битами значения и 0 битами заполнения».)
@abarnert спасибо, я явно неправильно понял работу CAS. Реализовано и протестировано с использованием верхних 16 бит в качестве счетчика и работает без проблем.