2009-03-05 11 views
9

Al leer acerca de la función InterlockedIncrement vi la observación de que la variable pasada debe alinearse en un límite de 32 bits. Normalmente he visto el código que utiliza el InterlockedIncrement así:InterlockedIncrement use

class A 
{ 
public: 
    A(); 
    void f(); 

private: 
    volatile long m_count; 
}; 

A::A() : m_count(0) 
{ 
} 

void A::f() 
{ 
    ::InterlockedIncrement(&m_count); 
} 

¿Funciona correctamente el código de seguridad en sistemas de varios procesadores o debería tener un poco más de cuidado para esto?

Respuesta

15

Depende de la configuración del compilador. Sin embargo, de forma predeterminada, cualquier elemento de ocho bytes o menos se alineará en un límite natural. Por lo tanto, un "int" nos alineará en un límite de 32 bits.

Además, la directiva "#pragma pack" se puede usar para cambiar la alineación dentro de una unidad de compilación.

Me gustaría agregar que la respuesta asume el compilador Microsoft C/C++. Las reglas de empaque pueden diferir de compilador a compilador. Pero en general, supondría que la mayoría de los compiladores C/C++ para Windows utilizan los mismos valores predeterminados de embalaje solo para facilitar el trabajo con encabezados de Microsoft SDK.

0

El código se ve bien (las variables se alinearán correctamente a menos que específicamente hagas algo para romper eso, por lo general involucrando fundición o estructuras 'empaquetadas').

0

Sí, esto funcionará bien. Los compiladores generalmente se alinean a menos que se indique lo contrario.

0

Estrictamente hablando, realmente depende del uso que haga de A; por ejemplo, si empaqueta un objeto "A" dentro de un shell ITEMIDLIST o una estructura con un "paquete pragma" incorrecto, es posible que los datos no se alineen correctamente.