Thread safety and member variables

  • Thread starter Thread starter Henri.Chinasque
  • Start date Start date
H

Henri.Chinasque

Hi all,

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? 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. 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).

thanks for helping with this seemingly simple question.
HC
 
Peter said:
No, not at all. What about that code makes you think it would be?
Click to expand...

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
 
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
Click to expand...

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
 
[...]
Actually the above code is thread safe.
It is also useless, so the benefits are not that big.
Arne
Click to expand...
Click to expand...
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?
Click to expand...

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.
Click to expand...

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).
 
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.
Click to expand...

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.
 
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?
Click to expand...

The code you posted is thread safe.

When you add all the real code, then it may be:
thread safe
not thread safe
If we introduce the volatile aspect it may be:
thread safe without volatile
not thread safe without volatile but thread safe with volatile
not thread safe with volatile

It depends on your code.

Arne
 
Peter said:
[...]
Actually the above code is thread safe.

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

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?
Click to expand...

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. :)
Click to expand...

Since it is impossible to guess whether the code not posted is thread
safe or not, then ...

Arne
 
Peter said:
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.
Click to expand...

You can not conclude that.

There are other ways of ensuring visibility between threads than
volatile.

Arne
 
Back
Top