C
Cool Guy
If I create an object for locking purposes, does it have to be volatile?
e.g.: readonly object fooLock = new Object();
e.g.: readonly object fooLock = new Object();
L
Lloyd Dupont
no
volatile keyword is only usefull for variable which could change a few time
in a given SINGLE method call.
because if they it's not volatile, the compiler could generate code which
just manipulate registry and update the value only when leaving the
function.
but in your case, it's update once and for all, who cares about volatility?
volatile keyword is only usefull for variable which could change a few time
in a given SINGLE method call.
because if they it's not volatile, the compiler could generate code which
just manipulate registry and update the value only when leaving the
function.
but in your case, it's update once and for all, who cares about volatility?
J
Jon Skeet [C# MVP]
Lloyd Dupont said:
Not really. It doesn't matter how many times it changes in a method
call - it matters whether you want changes from other threads to be
immediately visible. Even if the value in memory is changed when
leaving a method, there's no guarantee it'll be immediately visible to
other threads unless it's volatile.
See http://www.pobox.com/~skeet/csharp/threads/volatility.shtml
L
Lloyd Dupont
nice page Jon!
particularly thhe one about windows form, I was about to need to clarify my
knowledge on this
!
particularly thhe one about windows form, I was about to need to clarify my
knowledge on this
!
C
Cool Guy
Lloyd Dupont said:
Yeah. It's nice and clear.
FWIW, this is the only tutorial that I've ever read on the horrors of
multi-threading. Are there any others that I should read?
If they were specifically about .NET, too, then that'd be great -- but I
assume that Jon's is the only publicly-available one that's specifically
about .NET...
L
Lloyd Dupont
as said in your tutorial, one issue is the strong memory model of x86.
so you might wrote thread unsafe code without being aware of it!
And after reading your tutorial I think I might do have done it, it's just
that x86 are less thread bug prone!
I can't wait to test some multithread code on these new dual core processor,
so I could put my knowledge & understanding to the test!
so you might wrote thread unsafe code without being aware of it!
And after reading your tutorial I think I might do have done it, it's just
that x86 are less thread bug prone!
I can't wait to test some multithread code on these new dual core processor,
so I could put my knowledge & understanding to the test!
J
Jon Skeet [C# MVP]
Cool Guy said:
I'm sure there are others around, but they tend to skirt over things
like the memory model, just showing the basics. My page was originally
going to just show the basics, but it sort of took on a life of its
own...
(Lloyd's posted a link to a tutorial about Java threading, most of
which should be applicable to .NET. Java's memory model is slightly
weaker in some respects than .NET's (particularly regarding volatility)
but it's been strengthened somewhat for Java 5.0.)
C
Cool Guy
I wrote:
[snip]
So what's the rule for determining whether or not some shared data needs to
be volatile?
[snip]
So what's the rule for determining whether or not some shared data needs to
be volatile?
J
Jon Skeet [C# MVP]
Cool Guy said:
I almost never use volatile variables. Instead, whenever you access
(for reading or writing) data which is shared between threads, use a
lock.
The exception to this rule is for data which doesn't change, and which
is set up either before any of the reading threads are created, or
there is a memory barrier somewhere in each reading thread before any
reading happens.
C
Cool Guy
Jon Skeet said:
Aha!
L
Lloyd Dupont
After much thinking Jon I though that your explanation overstated number of
things.
Number of them I couldn't buy...
So I started hunting for litterature on the topic.
Turn out you that's an awfull topic..... fortunately very simple on x86 (but
remember, .NET runs on IA64...)
http://blogs.msdn.com/brada/archive/2004/05/12/130935.aspx
http://blogs.gotdotnet.com/cbrumme/PermaLink.aspx/480d3a6d-1aa8-4694-96db-c69f01d7ff2b
it's all the more difficult to test whan all you've got is an x86 :/
my comment: while multithreading is simple enough, multi-processor
implementation are broken
(except on x86
)
things.
Number of them I couldn't buy...
So I started hunting for litterature on the topic.
Turn out you that's an awfull topic..... fortunately very simple on x86 (but
remember, .NET runs on IA64...)
http://blogs.msdn.com/brada/archive/2004/05/12/130935.aspx
http://blogs.gotdotnet.com/cbrumme/PermaLink.aspx/480d3a6d-1aa8-4694-96db-c69f01d7ff2b
it's all the more difficult to test whan all you've got is an x86 :/
my comment: while multithreading is simple enough, multi-processor
implementation are broken
(except on x86
)
J
Jon Skeet [C# MVP]
Lloyd Dupont said:
I know a lot of it seems very unlikely, but that's because the memory
model is really pretty weak.
In some situations, however, that can be a real virtue. I know someone
who was part of a team to implement a distributed JVM. One machine
would hold "main" memory, and each of the other machines in the VM only
had "local" memory. At that point, you really don't want to have write
or read barriers very often, and you *really* need to make sure your
threading is safe
So I started hunting for litterature on the topic.
Turn out you that's an awfull topic..... fortunately very simple on x86 (but
remember, .NET runs on IA64...)
http://blogs.msdn.com/brada/archive/2004/05/12/130935.aspx
http://blogs.gotdotnet.com/cbrumme/PermaLink.aspx/480d3a6d-1aa8-4694-96db-c69f01d7ff2b
it's all the more difficult to test whan all you've got is an x86 :/
my comment: while multithreading is simple enough, multi-processor
implementation are broken
(except on x86
No, even on multi-processor it's possible to write it without any
thread safety issues. You just need to be very careful.