Thread safety and member variables

Edit:
m_floater = true should be m_floater = 17.7

On Wed, 13 Aug 2008 16:49:41 -0700, <He************ *@googlemail.co mwrote:

I am wondering about thread safety and member variables. If I have
such a class:

class foo {
private float m_floater = 0.0;
public void bar(){
m_floater = true;
}
}

Is the variable m_floater thread safe?

No, not at all. What about that code makes you think it would be?

If I write a test program and
run it in VS2005, the m_floater variable ends up in the locals window
in my debugger (for each thread) so it would seem that it is thread
safe.

Firstly, you're not going to see a member field show up in the "Locals"
window, except as a descendant of the implicit "this" variable. It's not
a local variable, but the "this" variable is. Second, if all it took to
make a member field "thread safe" was for it to be, well...a member field,
then all classes would be thread safe by default. That's definitely not
true.

I am assuming this would change if I made my member variable
into somthing that was stored on the managed heap? (i.e. each thread
has its own stack but there is only one heap available for storage).

Your class "foo" is a reference type, and so is always allocated from the
heap. So any instance fields are also stored on the heap, where the class
is (they are, after all, part of the class). You can't make your "member
variable into something that was stored on the managed heap". It already
is.

It's true that local variables are inherently thread safe, being
accessible only from the thread in which the method where they are
declared is executing. But that has nothing to do with things inside
classes, since you can't store a class in a local variable. You can only
store a _reference_ to a class in a local variable, and that reference
will always refer to data stored in the heap. Thus, without some sort of
synchronization , any instance member of the class is not thread safe (any
static member isn't either, but that's a separate question :) ).

Finally, lest you start thinking that this is a class-only thing, and that
value types (i.e. structs) then must be thread-safe, that would only be
true for structs that are only ever declared as local variables inside
methods. A struct used as the type for a member of a class would still
wind up being allocated on the heap with the rest of the class, and so
would not inherit the thread safety a struct declared as a local variable
would.

Pete

Peter Duniho wrote:

On Wed, 13 Aug 2008 16:49:41 -0700, <He************ *@googlemail.co mwrote:

>I am wondering about thread safety and member variables. If I have
such a class:

class foo {
private float m_floater = 0.0;
public void bar(){
m_floater = true;
}
}

Is the variable m_floater thread safe?

No, not at all. What about that code makes you think it would be?

Data are never thread safe in themselves. Data combined with
how they are used can be thread safe or not.

Actually the above code is thread safe.

It is also useless, so the benefits are not that big.

Arne

On Aug 13, 8:18 pm, Arne Vajhøj <a...@vajhoej.d kwrote:

Peter Duniho wrote:

On Wed, 13 Aug 2008 16:49:41 -0700, <Henri.Chinas.. .@googlemail.co mwrote:

I am wondering about thread safety and member variables. If I have
such a class:

class foo {
private float m_floater = 0.0;
public void bar(){
m_floater = true;
}
}

Is the variable m_floater thread safe?

No, not at all. What about that code makes you think it would be?

Data are never thread safe in themselves. Data combined with
how they are used can be thread safe or not.

Actually the above code is thread safe.

It is also useless, so the benefits are not that big.

Arne

I read Peter's response, makes great sense, thanks. So why then, do
you state that the above code is thread safe? Have I missed something
else?

thanks,
HC

On Wed, 13 Aug 2008 22:24:33 -0700, <He************ *@googlemail.co mwrote:

[...]

>Actually the above code is thread safe.

It is also useless, so the benefits are not that big.

Arne

I read Peter's response, makes great sense, thanks. So why then, do
you state that the above code is thread safe? Have I missed something
else?

Arne can be enigmatic sometimes. I suspect he does that intentionally.

Look at your class carefully. If we assume that that's _all_ of your
class, then there's nothing in it that could possibly be affected by
threading. No code in the class ever examines the "m_floater" variable
and it's private which means no code outside the class ever examines it
either. So it doesn't really matter if and when it gets assigned some new
value.

Personally, I figured that for the sake of discussion it made sense to
assume that there's more to your class than just what you posted.
Degenerate cases are mostly useful as base cases for induction, not
general conversation. :)

But clearly Arne felt otherwise, and took your code sample literally. And
yes, taken exactly as-is, there's no hazard using the class you posted in
a multi-threaded environment. In that sense, it's completely
thread-safe. :)

Pete

On Aug 14, 10:29*am, "Peter Duniho" <NpOeStPe...@nn owslpianmk.com>
wrote:

On Wed, 13 Aug 2008 22:24:33 -0700, <Henri.Chinas.. .@googlemail.co mwrote:

[...]

Actually the above code is thread safe.

It is also useless, so the benefits are not that big.

Arne

I read Peter's response, makes great sense, thanks. So why then, do
you state that the above code is thread safe? Have I missed something
else?

Arne can be enigmatic sometimes. *I suspect he does that intentionally.

Look at your class carefully. *If we assume that that's _all_ of your *
class, then there's nothing in it that could possibly be affected by *
threading. *No code in the class ever examines the "m_floater" variable*
and it's private which means no code outside the class ever examines it *
either. *So it doesn't really matter if and when it gets assigned some new *
value.

It's more than that. A single variable of certain types, including
bool (but in general, any primitive type with sizeof <= 4, IntPtr,
pointers, and object references), is always thread-safe with respect
to reads and writes which only touch that variable. It's because the
C# spec guarantees that all such reads and writes are atomic (on the
other hand, writing a long or a double variable may not be atomic, and
needs to be guarded in case of concurrent access).

On Wed, 13 Aug 2008 23:40:57 -0700, Pavel Minaev <in****@gmail.c omwrote:

>[...]
No code in the class ever examines the "m_floater" variable and it's
private which means no code outside the class ever examines it either.
Â*So it doesn't really matter if and when it gets assigned some new Â*
value.

It's more than that.

No, it really is just that.

A single variable of certain types, including
bool (but in general, any primitive type with sizeof <= 4, IntPtr,
pointers, and object references), is always thread-safe with respect
to reads and writes which only touch that variable.

Not true. First, if the variable isn't marked "volatile" (and it's not in
the example code we're talking about) it's still not thread-safe because
the compiler is allowed to generate code that could cache the value
somewhere invisible to some other thread.

In the code in question, the thread-safety comes only because it never
reads the variable. (By the way, because it always writes a constant,
even if the type wasn't 32 bits wide it'd still be safe, because all
writes would be doing the same thing).

More importantly, whether such a variable is thread-safe depends on how
it's used. Assuming the variable is properly marked as "volatile" and is
only ever assigned then yes, that would be thread-safe. But contrary to
your statement, being a type of 32 bits wide isn't in and of itself
sufficient for being thread-safe. For example:

class Test
{
volatile int i = 0;

void Method()
{
i = i + 1;
}
}

That's not thread-safe, even though the variable "i" is a 32 bit type.
There's more to thread-safety than just what the CPU can do with a
specific memory location.

Pete

On Aug 14, 10:52*am, "Peter Duniho" <NpOeStPe...@nn owslpianmk.com>
wrote:

A single variable of certain types, including
bool (but in general, any primitive type with sizeof <= 4, IntPtr,
pointers, and object references), is always thread-safe with respect
to reads and writes which only touch that variable.

Not true. *First, if the variable isn't marked "volatile" (and it's notin *
the example code we're talking about) it's still not thread-safe because *
the compiler is allowed to generate code that could cache the value *
somewhere invisible to some other thread.

Yes; I should have probably clarified that what I said was true only
with respect to a single read/write, not a sequence of those, even if
they all involve the same variable.

Of course, it is a moot point, since saying that "a variable is thread-
safe" - which is what I did - is a rather meaningless thing in and of
itself, since it's the code that can be thread-safe or not, not values
or storage locations by themselves. For values, the applicable term is
"atomic", which is what I should have used instead.

On Thu, 14 Aug 2008 00:44:10 -0700, Pavel Minaev <in****@gmail.c omwrote:

[...]
Of course, it is a moot point, since saying that "a variable is thread-
safe" - which is what I did - is a rather meaningless thing in and of
itself, since it's the code that can be thread-safe or not, not values
or storage locations by themselves. For values, the applicable term is
"atomic", which is what I should have used instead.

I agree. :) That's not exactly the same as "thread safe", though it's
related.

That said, you still need "volatile" if you expect to take advantage of
the atomicity as a part of thread-safety. Otherwise, you have nice atomic
reads and writes, but not necessarily to the same location each thread is
using.

Pete