more static + thread safety

On Aug 9, 8:13 am, Peter K <xdz...@hotmail.comwrote:

Say I have this class

public class Simple
{
private string name;

public string Name
{
get { return name; }
set { name = value; }
}

}

Is it "thread safe"?

No - not that that's necessarily a bad thing in itself. Most classes
don't need to be thread-safe, even if they're used in multi-threaded
environments. Instead, the classes using them need to take account of
the multi-threaded nature.

Multiple threads can certainly access their own instances of Simple
without problems...

Yes, but that's not what makes something thread-safe.

But what if I have another class which has a "static reference" to Simple:

public class StaticReference
{
private static Simple simple = new Simple();

public static Simple
{
get { return simple; }
}

}

Now if I have multiple threads accessing StaticReference then they can
upset each other by altering the Name property on the "simple" instance
they share, correct? So is "StaticReference" thread-safe?

StaticReference itself is thread-safe, but Simple isn't - classes
using StaticReference.Simple would need to take appropriate action to
ensure that they always see the most recent value of Name. This is
usually done through locking around any access to shared data.

See http://pobox.com/~skeet/csharp/threads for more information.

Jon

Peter K wrote:

Say I have this class

public class Simple
{
private string name;

public string Name
{
get { return name; }
set { name = value; }
}
}

Is it "thread safe"? Multiple threads can certainly access their own
instances of Simple without problems...

And just in case Jon's reply wasn't already clear enough:

As long as each thread has its own instance of Simple to use, then there
are no problems (as you already point out). But "thread-safe" means
that even if a single instance was shared between different threads,
data integrity would be ensured (note that this is different from
ensuring that the threads are cooperating :) ).

From your reply to Jon, it appears to me that you already understand
this now, but I figure it doesn't hurt to make sure.

Pete

Peter K wrote:

Say I have this class

public class Simple
{
private string name;

public string Name
{
get { return name; }
set { name = value; }
}
}

Is it "thread safe"? Multiple threads can certainly access their own
instances of Simple without problems...

And just in case Jon's reply wasn't already clear enough:

As long as each thread has its own instance of Simple to use, then there
are no problems (as you already point out). But "thread-safe" means
that even if a single instance was shared between different threads,
data integrity would be ensured (note that this is different from
ensuring that the threads are cooperating :) ).

From your reply to Jon, it appears to me that you already understand
this now, but I figure it doesn't hurt to make sure.

Pete

Peter K wrote:

Say I have this class

public class Simple
{
private string name;

public string Name
{
get { return name; }
set { name = value; }
}
}

Is it "thread safe"? Multiple threads can certainly access their own
instances of Simple without problems...

And just in case Jon's reply wasn't already clear enough:

As long as each thread has its own instance of Simple to use, then there
are no problems (as you already point out). But "thread-safe" means
that even if a single instance was shared between different threads,
data integrity would be ensured (note that this is different from
ensuring that the threads are cooperating :) ).

From your reply to Jon, it appears to me that you already understand
this now, but I figure it doesn't hurt to make sure.

Pete

Peter K wrote:

Say I have this class

public class Simple
{
private string name;

public string Name
{
get { return name; }
set { name = value; }
}
}

Is it "thread safe"? Multiple threads can certainly access their own
instances of Simple without problems...

And just in case Jon's reply wasn't already clear enough:

As long as each thread has its own instance of Simple to use, then there
are no problems (as you already point out). But "thread-safe" means
that even if a single instance was shared between different threads,
data integrity would be ensured (note that this is different from
ensuring that the threads are cooperating :) ).

From your reply to Jon, it appears to me that you already understand
this now, but I figure it doesn't hurt to make sure.

Pete

Peter K wrote:

Say I have this class

public class Simple
{
private string name;

public string Name
{
get { return name; }
set { name = value; }
}
}

Is it "thread safe"? Multiple threads can certainly access their own
instances of Simple without problems...

And just in case Jon's reply wasn't already clear enough:

As long as each thread has its own instance of Simple to use, then there
are no problems (as you already point out). But "thread-safe" means
that even if a single instance was shared between different threads,
data integrity would be ensured (note that this is different from
ensuring that the threads are cooperating :) ).

From your reply to Jon, it appears to me that you already understand
this now, but I figure it doesn't hurt to make sure.

Pete

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in
news:11********************@o61g2000hsh.googlegrou ps.com:

For instance, suppose I want to run something which changes everything
with a name of "Fred" to "Bill". If you do:

Simple simple = StaticReference.Simple;
if (simple.Name=="Fred")
{
simple.Name = "Bill";
}

then another thread could change the name from "Fred" to "Joe" between
the test and the set.

Right, thanks for the "food for thought". I can see that even with this
ultra-simple example all sorts of issues can crop up.

Even if Simple is thread-safe and StaticReference is thread-safe,
operations involving these classes may not be. (I think that's what you're
getting at).

So to ensure complete thread-safety it would be necessary to encapsulate
all operations involving Simple in a "SimpleOperations" class, and lock
over the complex operations there.

/Peter

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in
news:11********************@o61g2000hsh.googlegrou ps.com:

For instance, suppose I want to run something which changes everything
with a name of "Fred" to "Bill". If you do:

Simple simple = StaticReference.Simple;
if (simple.Name=="Fred")
{
simple.Name = "Bill";
}

then another thread could change the name from "Fred" to "Joe" between
the test and the set.

Right, thanks for the "food for thought". I can see that even with this
ultra-simple example all sorts of issues can crop up.

Even if Simple is thread-safe and StaticReference is thread-safe,
operations involving these classes may not be. (I think that's what you're
getting at).

So to ensure complete thread-safety it would be necessary to encapsulate
all operations involving Simple in a "SimpleOperations" class, and lock
over the complex operations there.

/Peter

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in
news:11********************@o61g2000hsh.googlegrou ps.com:

For instance, suppose I want to run something which changes everything
with a name of "Fred" to "Bill". If you do:

Simple simple = StaticReference.Simple;
if (simple.Name=="Fred")
{
simple.Name = "Bill";
}

then another thread could change the name from "Fred" to "Joe" between
the test and the set.

Right, thanks for the "food for thought". I can see that even with this
ultra-simple example all sorts of issues can crop up.

Even if Simple is thread-safe and StaticReference is thread-safe,
operations involving these classes may not be. (I think that's what you're
getting at).

So to ensure complete thread-safety it would be necessary to encapsulate
all operations involving Simple in a "SimpleOperations" class, and lock
over the complex operations there.

/Peter

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in
news:11********************@o61g2000hsh.googlegrou ps.com:

For instance, suppose I want to run something which changes everything
with a name of "Fred" to "Bill". If you do:

Simple simple = StaticReference.Simple;
if (simple.Name=="Fred")
{
simple.Name = "Bill";
}

then another thread could change the name from "Fred" to "Joe" between
the test and the set.

Right, thanks for the "food for thought". I can see that even with this
ultra-simple example all sorts of issues can crop up.

Even if Simple is thread-safe and StaticReference is thread-safe,
operations involving these classes may not be. (I think that's what you're
getting at).

So to ensure complete thread-safety it would be necessary to encapsulate
all operations involving Simple in a "SimpleOperations" class, and lock
over the complex operations there.

/Peter

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in
news:11********************@o61g2000hsh.googlegrou ps.com:

For instance, suppose I want to run something which changes everything
with a name of "Fred" to "Bill". If you do:

Simple simple = StaticReference.Simple;
if (simple.Name=="Fred")
{
simple.Name = "Bill";
}

then another thread could change the name from "Fred" to "Joe" between
the test and the set.

Right, thanks for the "food for thought". I can see that even with this
ultra-simple example all sorts of issues can crop up.

Even if Simple is thread-safe and StaticReference is thread-safe,
operations involving these classes may not be. (I think that's what you're
getting at).

So to ensure complete thread-safety it would be necessary to encapsulate
all operations involving Simple in a "SimpleOperations" class, and lock
over the complex operations there.

/Peter

Peter K wrote:

Even if Simple is thread-safe and StaticReference is thread-safe,
operations involving these classes may not be. (I think that's what you're
getting at).

Jon can clarify, but I'd say the answer to that is "no". By definition,
if the classes are "thread-safe" then operations involving those classes
are "thread-safe".

The classes can't be "thread-safe" unless all uses of the class are
thread-safe.

To further complicate matters, a class can have thread-safe members,
without the class itself being thread-safe. This would happen if
specific members were protected in a thread-safe way, but others were not.

So to ensure complete thread-safety it would be necessary to encapsulate
all operations involving Simple in a "SimpleOperations" class, and lock
over the complex operations there.

The Simple class itself could be made thread-safe. You don't need an
extra class, necessarily. Usually, a class that properly encapsulates
its implementation should be able to be made thread-safe without
introducing a new class (at least, not to the client of the class...you
may in fact need new data and/or classes in the implementation of
course, though in many cases this is as simple as adding an instance of
an object for locking purposes, and then adding the necessary "lock"
statements).

Pete