операции Win API ВЗАИМОСВЯЗАННОГО для 32-битного целого типа

Question

Если мы имеем:

__int32 some_var = 0; 

Что является лучшим (если таковые имеются) способ вызова InterlockedExchange, InterlockedIncrement и другие сблокированные функции, которые требуют LONG* для some_var?

Поскольку есть гарантия, что LONG - 32 бит на любой Windows, возможно, безопасно просто пройти (long*) some_var. Тем не менее, мне кажется довольно уродливым, и я не могу найти подтверждения, что это безопасно.

Примечание. Я не могу изменить тип на long, потому что он не переносится. Мне нужен ровно 32-битный тип.

Обновление: Некоторые исследования библиотек, которые обеспечивают переносные атомные операции, показали, что никто не беспокоится о литье. Некоторые примеры:

Apache Portable Runtime (APR):

typedef WINBASEAPI apr_uint32_t (WINAPI * apr_atomic_win32_ptr_val_fn) 
    (apr_uint32_t volatile *, 
    apr_uint32_t); 

APR_DECLARE(apr_uint32_t) apr_atomic_add32(volatile apr_uint32_t *mem, apr_uint32_t val) 
{ 
#if (defined(_M_IA64) || defined(_M_AMD64)) 
    return InterlockedExchangeAdd(mem, val); 
#elif defined(__MINGW32__) 
    return InterlockedExchangeAdd((long *)mem, val); 
#else 
    return ((apr_atomic_win32_ptr_val_fn)InterlockedExchangeAdd)(mem, val); 
#endif 
} 

atomic_ops:

AO_INLINE AO_t 
AO_fetch_and_sub1_full (volatile AO_t *p) 
{ 
    return _InterlockedDecrement64((LONGLONG volatile *)p) + 1; 
} 

Answer 1

Просто сделайте assert(sizeof(LONG) == sizeof(some_var)) и беспокоитесь только о проблеме, когда утверждение не выполнено. YAGNI. Пока это утверждение выполняется, вы можете использовать reinterpret_cast<LONG*>(&some_var).

Answer 2

Вы могли бы также изменить тип на долго, оставляя за портативности, так как весь "блокированы" семейство атомарных операций также не переносится.

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

Answer 3

Ну, это камень и трудное место. Атомное приращение представляет собой детальную реализацию платформы с большой нагрузкой. Вот почему LONG typedef существует в первую очередь. Некоторая будущая операционная система через 20 или 50 лет может переопределить этот тип. Когда, скажем, 256-битные ядра являются общими, а атомные приращения работают по-разному. Кто знает.

Если вы хотите написать действительно портативный код, тогда вы должны использовать действительно переносные типы. Как ДОЛГО. И это будет бременем Microsoft, чтобы заставить его работать вместо ваших.

Это будет 32-битное целое число в течение довольно долгого времени, я бы рекомендовал вам не беспокоиться об этом.

Answer 4

Ну, не является переносным типом . Поэтому мое предложение по устранению проблемы - использовать typedef. В Windows, вы можете сделать:

typedef LONG my_int32; 

... и безопасно передать указатель на такой тип для InterlockedExchange(). В других системах, использовать все это 32 бит типа там - например, если у них есть stdint.h, вы можете сделать:

typedef int32_t my_int32; 

Answer 5

достаточно Занятно, есть InterlockedExchange - это окна API, который принимает LONG * и _InterlockedExchange msvc встроенный, который занимает длинный *.

Поскольку мобильность была вызвана, Ill также ссылается на страницу на GCC atomic intrinsics.

Точка хорошо взята: MSVC использует ILP32LLP64 data model для 32-битных сборок и LLP64 для 64-битных сборок. Комбинированные на основе GCC (например, MinGW) существуют для окон и могут очень хорошо реализовать модель LP64, что приводит к забавному! таких как «длинный», 64 бит, но LONG равен 32.

Если вы придерживаетесь компиляторов Microsoft, вам не о чем беспокоиться.

Итак, в заключение: 1. Передаваемая стоимость ДОЛЖНА быть квалифицирована как «изменчивый». 2. Потому что вы (a) используете 32-битное количество (и это требование youre) и (b), используя явно 32-битную форму InterlockedXXX API - ее 100% -ный сейф, чтобы просто сделать чертову бросок и сделать с ней: InterlockedIncrement будет работать с 32-битным значением для всех размеров бит, ваша переменная будет явно 32 бит на всех размерах бит - даже при использовании разных моделей данных.

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

Answer 6

Hans Passant выразил это очень хорошо:

«Атомное приращение представляет собой сверхмощная деталь реализации платформы.»

Именно поэтому реализации обеспечивают специфические перегрузки типа.

atomic_ops является одним из таких проектов.

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

В этом отношении происходит стандартизация, см., Например, аналогичные вопросы ответили here и here.