Thread-safe

Hi Senna,
1. -> yes, at least in .Net (I beleive this will not be thread safe in
Java, at least before 1.5, but I am no Java expert). There are some other
easier ways to achieve what you are doing, for example just delare an
instance of the Adapter class when you define the variable i.e.

private static Adapter _instance = new Adapter();

since the instnace it static it is guaranteed to only get instantiated once
even across multiple threads, plus now you don't have the overhead of
acquiring the lock each time someone accesses the instance property (not that
it is really that much of an overhead, but if its not necessary no need to do
it :-) ).

2. You need to use the lock keyword every time you are trying to
access/modify a resource that is being shared. In your case I would say the
Foo1 set needs a lock because you might be inside one of your other methods
using the Foo1 variable and you don't want it being modified half way
through. I would lock just like you have apart from the Foo1 get which since
it is only one atomic operation I don't believe that you need to lock on that.

For a really good tutorial on Threading see:
http://www.yoda.arachsys.com/csharp/threads/

Hope that helps
Mark Dawson
http://www.markdawson.org

"Senna" wrote:

Hi

I have some questions about this code, http://code.doria.se/?c=18.

1. Will the Adapter class be thread-safe?

2. In the #region Way 1 I use lock(_lockobj) every time I go about and do
something, is this necessary?

3. If the answer in question 2 is no, when are one suppose to use lock()? Or
is it enough with what going on in Instance.

4. Anything else I need to know?

Thanks

Hi Mark.

In the tutorial, great by the way, he says: "For "static locks" you should
declare a private static variable (and immediately instantiate a new object)
for the same reason - other classes can get a Type reference to your type
too! While it is unlikely that they would lock on your type, it's not
impossible - a private static variable keeps the lock invisible to other
classes. In both cases, make the variable read-only to stop yourself from
accidentally changing the value."

This is a little over my head, but...

If I use
private static Adapter _instance = new Adapter();
wouldn't that mean I lock on something that could be tampered with? Cause it
is the _instance that gets returned.
But if I use
private static object _lockObj = new object();
that object would only be used internally to lock() on.

And he says "immediatel y instantiate a new object" do that mean object like
= new object();
or do
= new Adapter();
actually go under that definition too.

He also recommends to set it as readonly.
private static readonly Adapter _instance = new Adapter();
Does that make any difference when using "new object();" or "new Adapter();".

Or should this be enough.

private static readonly Adapter _instance = new Adapter();

public static Adapter Instance
{
get { return _instance; }
}
/ Senna

"Mark R. Dawson" wrote:

Hi Senna,
1. -> yes, at least in .Net (I beleive this will not be thread safe in
Java, at least before 1.5, but I am no Java expert). There are some other
easier ways to achieve what you are doing, for example just delare an
instance of the Adapter class when you define the variable i.e.

private static Adapter _instance = new Adapter();

since the instnace it static it is guaranteed to only get instantiated once
even across multiple threads, plus now you don't have the overhead of
acquiring the lock each time someone accesses the instance property (not that
it is really that much of an overhead, but if its not necessary no need to do
it :-) ).

2. You need to use the lock keyword every time you are trying to
access/modify a resource that is being shared. In your case I would say the
Foo1 set needs a lock because you might be inside one of your other methods
using the Foo1 variable and you don't want it being modified half way
through. I would lock just like you have apart from the Foo1 get which since
it is only one atomic operation I don't believe that you need to lock on that.

For a really good tutorial on Threading see:
http://www.yoda.arachsys.com/csharp/threads/

Hope that helps
Mark Dawson
http://www.markdawson.org

"Senna" wrote:

Hi

I have some questions about this code, http://code.doria.se/?c=18.

1. Will the Adapter class be thread-safe?

2. In the #region Way 1 I use lock(_lockobj) every time I go about and do
something, is this necessary?

3. If the answer in question 2 is no, when are one suppose to use lock()? Or
is it enough with what going on in Instance.

4. Anything else I need to know?

Thanks

Senna <Se***@discussi ons.microsoft.c om> wrote:

In the tutorial, great by the way, he says: "For "static locks" you should
declare a private static variable (and immediately instantiate a new object)
for the same reason - other classes can get a Type reference to your type
too! While it is unlikely that they would lock on your type, it's not
impossible - a private static variable keeps the lock invisible to other
classes. In both cases, make the variable read-only to stop yourself from
accidentally changing the value."

This is a little over my head, but...

If I use
private static Adapter _instance = new Adapter();
wouldn't that mean I lock on something that could be tampered with? Cause it
is the _instance that gets returned.
Yes, that's a bad idea - someone else might lock on it.
But if I use
private static object _lockObj = new object();
that object would only be used internally to lock() on.
Yes, that's the way to go.
And he says "immediatel y instantiate a new object" do that mean object like
= new object();
or do
= new Adapter();
actually go under that definition too.

He also recommends to set it as readonly.
private static readonly Adapter _instance = new Adapter();
Does that make any difference when using "new object();" or "new Adapter();".

It makes no odds to whether you use Adapter or Object as your lock
type, but I'd recommend using object (and making it an object which is
used for no other purpose) for the reasons stated.

--
Jon Skeet - <sk***@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

Ok, I will go with the object then.

One more question. The advise above was to use lock() when I should access
shared data. Does this include when I go to a database too, to do any CRUD
actions. I mean could muliple threads go in and use the same database
connection. Wonder this because the SqlMembership and Role Providers don't
use lock() for this.

"Jon Skeet [C# MVP]" wrote:

Senna <Se***@discussi ons.microsoft.c om> wrote:

In the tutorial, great by the way, he says: "For "static locks" you should
declare a private static variable (and immediately instantiate a new object)
for the same reason - other classes can get a Type reference to your type
too! While it is unlikely that they would lock on your type, it's not
impossible - a private static variable keeps the lock invisible to other
classes. In both cases, make the variable read-only to stop yourself from
accidentally changing the value."

This is a little over my head, but...

If I use
private static Adapter _instance = new Adapter();
wouldn't that mean I lock on something that could be tampered with? Cause it
is the _instance that gets returned.

Yes, that's a bad idea - someone else might lock on it.

But if I use
private static object _lockObj = new object();
that object would only be used internally to lock() on.

Yes, that's the way to go.

And he says "immediatel y instantiate a new object" do that mean object like
= new object();
or do
= new Adapter();
actually go under that definition too.

He also recommends to set it as readonly.
private static readonly Adapter _instance = new Adapter();
Does that make any difference when using "new object();" or "new Adapter();".

It makes no odds to whether you use Adapter or Object as your lock
type, but I'd recommend using object (and making it an object which is
used for no other purpose) for the reasons stated.

--
Jon Skeet - <sk***@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

Senna wrote:

Ok, I will go with the object then.

One more question. The advise above was to use lock() when I should access
shared data. Does this include when I go to a database too, to do any CRUD
actions. I mean could muliple threads go in and use the same database
connection. Wonder this because the SqlMembership and Role Providers don't
use lock() for this.

Each database action should open the database connection and close it.
The connection pooling will work out what to do with the physical
connections. This way you should never end up with two different
threads sharing the same physical connection.

Wherever possible, write your code so that it doesn't *need* to be
thread-safe - many, many objects only really need to be used by a
single thread, or maybe a single thread at a time, and it makes life a
lot easier to work that way.

Jon

The obvious question that pops up, how do one know it doesn't *need* to be
thread-safe? Maybe a wide question to answer so do you know any articles
about it?

"Jon Skeet [C# MVP]" wrote:

Senna wrote:

Ok, I will go with the object then.

One more question. The advise above was to use lock() when I should access
shared data. Does this include when I go to a database too, to do any CRUD
actions. I mean could muliple threads go in and use the same database
connection. Wonder this because the SqlMembership and Role Providers don't
use lock() for this.

Each database action should open the database connection and close it.
The connection pooling will work out what to do with the physical
connections. This way you should never end up with two different
threads sharing the same physical connection.

Wherever possible, write your code so that it doesn't *need* to be
thread-safe - many, many objects only really need to be used by a
single thread, or maybe a single thread at a time, and it makes life a
lot easier to work that way.

Jon

Senna wrote:

The obvious question that pops up, how do one know it doesn't *need* to be
thread-safe? Maybe a wide question to answer so do you know any articles
about it?

You advertise whether or not it *is* thread-safe, and adapt it
appropriately. I find that classes which aren't aware of being used by
multiple threads (i.e. they're not doing thready things themselves)
usually don't need to be thread-safe. It's a good starting point to
assume they don't need to be, then make them more thread-safe where
necessary.

(Making static members thread-safe is a good idea, however.)

Jon

Ok, I think I got it know. Finally. :)

Thanks for your time and knowledge.

/ Senna

"Jon Skeet [C# MVP]" wrote:

Senna wrote:

The obvious question that pops up, how do one know it doesn't *need* to be
thread-safe? Maybe a wide question to answer so do you know any articles
about it?

You advertise whether or not it *is* thread-safe, and adapt it
appropriately. I find that classes which aren't aware of being used by
multiple threads (i.e. they're not doing thready things themselves)
usually don't need to be thread-safe. It's a good starting point to
assume they don't need to be, then make them more thread-safe where
necessary.

(Making static members thread-safe is a good idea, however.)

Jon