lock på en value type..

long har en Int64 struct helt ligesom int har en Int32 struct.

struct er value typer som du ikke kan lave lock på.

Du vbliver nødt til at lave et shadow objekt som du bruger til at
låse på i.s.f. den long.

Og det er helt rigtigt at kun data typer op til 4 bytes kan
erklæres volatile.

Og det hænger sammen med at systemer med instruktioner som opererer på
32 bit enheder, så er en operation på en 8 byte data typer flere
instruktioner og så er det meget vanskeligt at håndtere volatile.

Som et kuriusom kan jeg citere fra Java Language Spec:

17.4 Nonatomic Treatment of double and long
If a double or long variable is not declared volatile, then for the purposes of load, store, read, and write actions they are treated as if they were two variables of 32 bits each: wherever the rules require one of these actions, two such actions are performed, one for each 32-bit half. The manner in which the 64 bits of a double or long variable are encoded into two 32-bit quantities is implementation-dependent. The load, store, read, and write actions on volatile variables are atomic, even if the type of the variable is double or long.

This matters only because a read or write of a double or long variable may be handled by an actual main memory as two 32-bit read or write actions that may be separated in time, with other actions coming between them. Consequently, if two threads concurrently assign distinct values to the same shared non-volatile double or long variable, a subsequent use of that variable may obtain a value that is not equal to either of the assigned values, but some implementation-dependent mixture of the two values.

An implementation is free to implement load, store, read, and write actions for double and long values as atomic 64-bit actions; in fact, this is strongly encouraged. The model divides them into 32-bit halves for the sake of several currently popular microprocessors that fail to provide efficient atomic memory transactions on 64-bit quantities. It would have been simpler to define all memory transactions on single variables as atomic; this more complex definition is a pragmatic concession to current hardware practice. In the future this concession may be eliminated. Meanwhile, programmers are cautioned always to explicitly synchronize access to shared double and long variables.

Og et svar !

:-)

Nå men det gjorde jeg så... boxing / unboxing nu har jeg forstået hvad det er..

Tak