2010-08-02 12 views
5

Una cita de MSDNInt64 (largo) e hilo de seguridad

Asignación de una instancia de este tipo no es seguro para subprocesos en todas las plataformas de hardware debido a que la representación binaria de esa instancia podría ser demasiado grande para asignar en una sola operación atómica

¿Quiere decir que Thead-safe en procesadores de 64 bits como Itianium o x86-64 también?

Por ejemplo:

long data = GetData(); 
// some parallel task on data 

podría ser un problema?

+0

Vea también http://stackoverflow.com/questions/596065/under-c-is-int64-use-on-a-32-bit-processor-dangerous –

Respuesta

2

Posiblemente, pero ¿por qué escribir un programa que será seguro para subprocesos en algunas plataformas Intel workalike, pero no en otras? Tenga en cuenta que los tipos Decimal y Double también tienen esta exención de responsabilidad sobre seguridad de hilos.

Microsoft recomienda el uso de bloqueos en estos casos. Hay enlaces a una buena información acerca de la concurrencia, la asignación de memoria y bloqueos de bajo nivel aquí:

http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread/f03ea3c9-4c2b-4a79-8f8c-4a6b7476b20d

0

Es un problema si se accede directamente a la variable data por código de subprocesos diferentes.

No garantizan ningún sistema específico, por lo que supongo que no es seguro para los sistemas x64 y x86, aunque sospecho que lo que realmente tenían en mente eran lugares como el marco compacto que ejecuta en teléfonos inteligentes.

+0

pero int32 no tiene esta nota, ya que debe ser relacionada con la arquitectura (x64 x86) –

0

Me errar en el lado seguro y no asumir.

Nota this pregunta anterior. Esencialmente, para la asignación atómica a Int64s debes mirar usando la clase Interlocked.

Consulte this link también para un análisis más detallado. En particular, consulte la sección etiquetada: "Atomicity and Interlocked".

0

El quid de la cuestión aquí es que Int64 no es garantizado para ser atómico, pero eso no impide que sea así en algunos casos. En otras palabras, Int64 sería atómico en sistemas de 64 bits. Por supuesto, eso no significa que sea necesariamente seguro para subprocesos. Hay otros problemas con respecto a la seguridad de la hebra además de la atomicidad. Para evitar el problema estancamiento, por ejemplo, tendría que utilizar las directivas de memoria adecuada barrera (volatile, Thread.VolatileWrite, etc.)

1

operaciones de carga/almacenamiento de memoria se consideran atómica si se realizan en trozos de memoria que se colocan en una dirección de memoria alineada y no son más grandes que el puntero nativo del tamaño de la máquina.
Lo que significa que a una operación de carga/almacenamiento de 64 bits en una dirección de memoria alineada será atómica en una plataforma de 64 bits, pero no será atómica en una plataforma de 32 bits.

Los procesadores modernos ofrecen un conjunto especial de instrucciones (en .Net, la mayoría de ellas están expuestas a través de la clase Interlocked). que permiten alcanzar la atomicidad en operaciones de carga/almacenamiento que son más grandes que el tamaño del puntero nativo de la máquina (operaciones de 64 bits en procesadores de 32 bits y operaciones de 128 bits en procesadores de 64 bits).Este último no está expuesto por la clase Interlocked, pero está disponible en código nativo).

Para obtener más información, consulte la publicación de Joe Duffy: Thread-safety, torn reads, and the like.

+0

Friendly heads up: http://www.bluebytesoftware.com/blog/CommentView,guid,c40a187f-4eeb-43c9-8532-35d480abd1e1.aspx es un enlace inactivo – Rick

+0

Encontré el enlace de estar http: //joeduffyblog.com/2006/02/07/threadsafety-torn-reads-and-the-like/ – Rick