When is "volatile" used instead of "lock" ?

[Brian Gideon]

Re: When is "volatile& quot; used instead of "lock&quot ; ?

On Aug 2, 4:38 pm, Arne Vajhøj <a...@vajhoej.d kwrote:

Jon Skeet [C# MVP] wrote:
>

Is anyone still interested in me replying to this post? I've left it
for a while because it'll take a fair amount of replying, but I won't
bother if no-one's interested any more :)

>
I consider it very likely that someone will find it useful
within the next 5-10 years.
>
Besides the original poster and participants, then there
are always those that find the thread via Google later.
>
Arne

I second that. I haven't been participating in this thread, but I
have been watching it with interest.

[Ben Voigt [C++ MVP]]

Re: When is &quot;volatile& quot; used instead of &quot;lock&quot ; ?

One of the interesting parts of the .NET 2.0 model is that all writes

during a constructor are made visible before the new reference itself
is made visible. Maybe that's something to do with the apparent
contradiction?

I'm pretty sure this is not true in .NET. The "this" keyword is available
in the constructor. Only Spec# complains if you try to use it, because the
invariants may not yet hold.

[Jon Skeet [C# MVP]]

Re: When is &quot;volatile& quot; used instead of &quot;lock&quot ; ?

Ben Voigt [C++ MVP] <rbv@nospam.nos pamwrote:

One of the interesting parts of the .NET 2.0 model is that all writes
during a constructor are made visible before the new reference itself
is made visible. Maybe that's something to do with the apparent
contradiction?

>
I'm pretty sure this is not true in .NET. The "this" keyword is available
in the constructor. Only Spec# complains if you try to use it, because the
invariants may not yet hold.

I think we may be talking at cross-purposes. I'm talking about a
situation which is theoretically possible in the CLI model, but not in
the .NET 2.0 model:

public class Foo
{
public int Bar; // Yeah, but with a property etc

public Foo(int b)
{
Bar = b;
}
}


Thread 1: Thread 2:
sharedVar = new Foo(10);
Console.WriteLi ne(sharedVar.Ba r);


In theory (with the ECMA model), sharedVar's new value can be visible
to thread 2 before the write to sharedVar.Bar - meaning that thread 2
could end up printing "0".

That has been tightened up in the .NET 2.0 memory model.

--
Jon Skeet - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Ben Voigt [C++ MVP]]

Re: When is &quot;volatile& quot; used instead of &quot;lock&quot ; ?


"Jon Skeet [C# MVP]" <skeet@pobox.co mwrote in message
news:MPG.2121a1 26ace1208836b@m snews.microsoft .com...

Ben Voigt [C++ MVP] <rbv@nospam.nos pamwrote:

One of the interesting parts of the .NET 2.0 model is that all writes
during a constructor are made visible before the new reference itself
is made visible. Maybe that's something to do with the apparent
contradiction?

>>
>I'm pretty sure this is not true in .NET. The "this" keyword is
>available
>in the constructor. Only Spec# complains if you try to use it, because
>the
>invariants may not yet hold.

>
I think we may be talking at cross-purposes. I'm talking about a
situation which is theoretically possible in the CLI model, but not in
the .NET 2.0 model:
>
public class Foo
{
public int Bar; // Yeah, but with a property etc
>
public Foo(int b)
{
Bar = b;
}
}
>
>
Thread 1: Thread 2:
sharedVar = new Foo(10);
Console.WriteLi ne(sharedVar.Ba r);
>
>
In theory (with the ECMA model), sharedVar's new value can be visible
to thread 2 before the write to sharedVar.Bar - meaning that thread 2
could end up printing "0".
>
That has been tightened up in the .NET 2.0 memory model.

That's related to the result of the new expression, though, not visibility
of the new reference. What if the Foo constructor had "sharedVar = this;"?

>
--
Jon Skeet - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Re: When is &quot;volatile& quot; used instead of &quot;lock&quot ; ?

Ben Voigt [C++ MVP] <rbv@nospam.nos pamwrote:

That has been tightened up in the .NET 2.0 memory model.

>
That's related to the result of the new expression, though, not visibility
of the new reference.

Well, it's the result of the new reference becoming visible before all
the writes in the constructor are necessarily visible.

What if the Foo constructor had "sharedVar = this;"?

Then you could have an equally nasty situation.

--
Jon Skeet - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too