> "
> The volatile modifier is usually used for a field that is accessed by
> multiple threads without using the lock Statement (C# Reference)
> statement to serialize access.
> "

> But when is it better to use "volatile" instead of "lock" ?

> Thanks,

> Sam

> ------------------------------------------------------------
> We're hiring!  B-Line Medical is seeking .NET
> Developers for exciting positions in medical product
> development in MD/DC.  Work with a variety of technologies
> in a relaxed team environment.  See ads on Dice.com.

> Seealso: http://www.albahari.com/threading/part4.html

>> "
>> The volatile modifier is usually used for a field that is accessed by
>> multiple threads without using the lock Statement (C# Reference)
>> statement to serialize access.
>> "

>> But when is it better to use "volatile" instead of "lock" ?

>> Thanks,

>> Sam

>> ------------------------------------------------------------
>> We're hiring!  B-Line Medical is seeking .NET
>> Developers for exciting positions in medical product
>> development in MD/DC.  Work with a variety of technologies
>> in a relaxed team environment.  See ads on Dice.com.

> You can also the System.Threading.Interlocked class which maintains
> volatile semantics.

> Seealso: http://www.albahari.com/threading/part4.html

> <ben.bidding...@gmail.com> wrote in message
> news:1179761300.206885.51230@z28g2000prd.googlegroups.com...
>> On May 21, 3:35 pm, Samuel R. Neff <samueln...@nomail.com> wrote:
>>> When is it appropriate to use "volatile" keyword?  The docs simply
>>> state:

>>> "
>>> The volatile modifier is usually used for a field that is accessed by
>>> multiple threads without using the lock Statement (C# Reference)
>>> statement to serialize access.
>>> "

>>> But when is it better to use "volatile" instead of "lock" ?

>>> Thanks,

>>> Sam

>>> ------------------------------------------------------------
>>> We're hiring!  B-Line Medical is seeking .NET
>>> Developers for exciting positions in medical product
>>> development in MD/DC.  Work with a variety of technologies
>>> in a relaxed team environment.  See ads on Dice.com.

>> You can also the System.Threading.Interlocked class which maintains
>> volatile semantics.

> You should use volatile and Interlocked together, neither fully replaces
> the other.

>> <ben.bidding...@gmail.com> wrote in message
>> news:1179761300.206885.51230@z28g2000prd.googlegroups.com...
>>> On May 21, 3:35 pm, Samuel R. Neff <samueln...@nomail.com> wrote:
>>>> When is it appropriate to use "volatile" keyword?  The docs simply
>>>> state:

>>>> "
>>>> The volatile modifier is usually used for a field that is accessed by
>>>> multiple threads without using the lock Statement (C# Reference)
>>>> statement to serialize access.
>>>> "

>>>> But when is it better to use "volatile" instead of "lock" ?

>>>> Thanks,

>>>> Sam

>>>> ------------------------------------------------------------
>>>> We're hiring!  B-Line Medical is seeking .NET
>>>> Developers for exciting positions in medical product
>>>> development in MD/DC.  Work with a variety of technologies
>>>> in a relaxed team environment.  See ads on Dice.com.

>>> You can also the System.Threading.Interlocked class which maintains
>>> volatile semantics.

>> You should use volatile and Interlocked together, neither fully replaces
>> the other.

> Not necessarily, there is no need for volatile, as long you Interlock
> consistently across all threads in the process. This means that once you
> access a shared variable using Interlock, all threads should use
> Interlock.

> Willy.

> Note that this is not a problem for pass-by-pointer, which must use the true
> address of the referenced variable in order to enable pointer arithmetic.
> But pointer arithmetic isn't allowed for tracking handles, a handle is an
> opaque value anyway.

> For lockless data structures, always use volatile.  And then stick that
> volatile variable close in memory to what it is protecting, because CPU
> cache has to load and flush an entire cache line at once, and volatile write
> semantics require flushing all pending writes.

>> Note that this is not a problem for pass-by-pointer, which must use the
>> true
>> address of the referenced variable in order to enable pointer arithmetic.
>> But pointer arithmetic isn't allowed for tracking handles, a handle is an
>> opaque value anyway.

>> For lockless data structures, always use volatile.  And then stick that
>> volatile variable close in memory to what it is protecting, because CPU
>> cache has to load and flush an entire cache line at once, and volatile
>> write
>> semantics require flushing all pending writes.

> The Interlocked methods have volatile semantics.  So as long as you
> consistently use them for both reading and writing the end result
> should be the same.

> Inside the implementation.

>> Inside the implementation.

> No, inside the JIT which has to notice that you call Interlocked.

>> But who guarantees that the variable atomically
>> read and written to, is your so-called "end result"?

> The CLI spec.

> By the way, if you pass volatile parameters by reference, the
> volatility is irrelevant as far as the called method is concerned
> anyway - it even triggers a warning from the compiler (CS0420).

> Jon