lock

[RedLars]

This [1] article at msdn describes the lock statments and gives a few
guidelines. After reading that article I had two small questions.

1. What is the difference between
private List<string> list = new List<string>();
private object lock = new object();
public void Add(string str)
{
lock(lock) list.Add(str);
}

and
private List<string> list = new List<string>();
public void Add(string str)
{
lock(list) list.Add(str);
}

2. Why set an lockerObjects as readonly? What does that accomplish?

Are there any other guidelines to consider when using lock?

[1] - http://msdn.microsoft.com/en-us/library/c5kehkcz.aspx

 

[Arne Vajhøj]

This [1] article at msdn describes the lock statments and gives a few
guidelines. After reading that article I had two small questions.

1. What is the difference between
private List<string> list = new List<string>();
private object lock = new object();
public void Add(string str)
{
lock(lock) list.Add(str);
}

and
private List<string> list = new List<string>();
public void Add(string str)
{
lock(list) list.Add(str);
}

You lock on different objects. It is important that all
threads that need to be synchronized for accessing something
lock on the same object.

2. Why set an lockerObjects as readonly? What does that accomplish?

That the variable can not be assigned a ref to a different object.

Which is somewhat nice given the what it will be used for.

Arne

 

[Jeroen Mostert]

This [1] article at msdn describes the lock statments and gives a few
guidelines. After reading that article I had two small questions.

1. What is the difference between
private List<string> list = new List<string>();
private object lock = new object();
public void Add(string str)
{
lock(lock) list.Add(str);
}

and
private List<string> list = new List<string>();
public void Add(string str)
{
lock(list) list.Add(str);
}

In this case, none. The essence is that you should lock on a private member
that logically defines mutual exclusion. If you have a suitable private
object, you can use it directly. In this case, the lock's purpose is to
guarantee mutual exclusion to the list (and only the list) so you can lock
on the list itself.

In general, you'll need mutual exclusion for more complicated bits of code
that use multiple objects. Since there is no one object that conveniently
expresses the mutual exclusion condition, you declare a dummy one for the
sole purpose of locking.

2. Why set an lockerObjects as readonly? What does that accomplish?

Because you definitely do not want the field to be reassigned. That could
lead to serious errors, as you could no longer assume that code which locks
on the same field runs under mutual exclusion, since they could be locking
on different objects. In the example above, if "list" could ever change, it
would be a bad idea to directly use it for locking.

 

[RedLars]

This [1] article at msdn describes the lock statments and gives a few
guidelines. After reading that article I had two small questions.

1. What is the difference between
private List<string> list = new List<string>();
private object lock = new object();
public void Add(string str)
{
  lock(lock) list.Add(str);
}

and
private List<string> list  = new List<string>();
public void Add(string str)
{
  lock(list) list.Add(str);
}

You lock on different objects. It is important that all
threads that need to be synchronized for accessing something
lock on the same object.

Let me rephrase.

Does introducing 'object lock' in example1 improve the code in any
way?

 

[Arne Vajhøj]

This [1] article at msdn describes the lock statments and gives a few
guidelines. After reading that article I had two small questions.
1. What is the difference between
private List<string> list = new List<string>();
private object lock = new object();
public void Add(string str)
{
lock(lock) list.Add(str);
}
and
private List<string> list = new List<string>();
public void Add(string str)
{
lock(list) list.Add(str);
}

You lock on different objects. It is important that all
threads that need to be synchronized for accessing something
lock on the same object.

Let me rephrase.

Does introducing 'object lock' in example1 improve the code in any
way?

The code snippets given does not in themselves require any
locking at all.

Everything depends on the context not given here.

You can use a central lock object to coordinate access
to multiple objects.

You have to use a lock object for value types.

On the other hand you can not use that private lock object
if you need to synchronize access to the list in other classes.

It all depends !

Arne

 

[miher]

Hi,
By selecting the correct lock object You can -lets say- "scope" Your lock.
If You use a designated lockobject You can be sure that no one else will use
that (since lock objects usually not exposed out of the given instance.)
However if You use the list itself as lock object and You(or someone else
who extends Your code) expose it to outside of the object (returned from a
property or function for example), nothing will prevent users of Your class
to save that reference and use it, even for locking. It can happen that for
some reason You _have_ to expose the list but You want to keep the control
over the lock used.
To make it short: when lock object is used You can be sure that You alone
have control over the lock (again only if You dont expose the lockobject).

As I know having a readonly lock mostly useful for code readibility, and for
Your own safety. By declaring it readonly You explicitly say that it is not
intended to be changed, what helps people understand Your code, and also
prohibits situations when Your lock might be "messed" with.

Hope You find this useful.
-Zsolt

 

[Arne Vajhøj]

This [1] article at msdn describes the lock statments and gives a few
guidelines. After reading that article I had two small questions.

1. What is the difference between
private List<string> list = new List<string>();
private object lock = new object();
public void Add(string str)
{
lock(lock) list.Add(str);
}

and
private List<string> list = new List<string>();
public void Add(string str)
{
lock(list) list.Add(str);
}

By selecting the correct lock object You can -lets say- "scope" Your
lock. If You use a designated lockobject You can be sure that no one
else will use that (since lock objects usually not exposed out of the
given instance.) However if You use the list itself as lock object and
You(or someone else who extends Your code) expose it to outside of the
object (returned from a property or function for example), nothing will
prevent users of Your class to save that reference and use it, even for
locking. It can happen that for some reason You _have_ to expose the
list but You want to keep the control over the lock used.
To make it short: when lock object is used You can be sure that You
alone have control over the lock (again only if You dont expose the
lockobject).

But whether that is a desirable or non-desirable effect depends
on whether the list is exposed or not.

Arne

 

[RedLars]

Hi,
By selecting the correct lock object You can -lets say- "scope" Your lock..
If You use a designated lockobject You can be sure that no one else will use
that (since lock objects usually not exposed out of the given instance.)
However if You use the list itself as lock object and You(or someone else
who extends Your code) expose it to outside of the object (returned from a
property or function for example), nothing will prevent users of Your class
to save that reference and use it, even for locking. It can happen that for
some reason You _have_ to expose the list but You want to keep the control
over the lock used.
 To make it short: when lock object is used You can be sure that You alone
have control over the lock (again only if  You dont expose the lockobject).

As I know having a readonly lock mostly useful for code readibility, and for
Your own safety. By declaring it readonly You explicitly say that it is not
intended to be changed, what helps people understand Your code, and also
prohibits situations when Your lock might be "messed" with.

Hope You find this useful.
-Zsolt

This [1] article at msdn describes the lock statments and gives a few
guidelines. After reading that article I had two small questions.

1. What is the difference between
private List<string> list = new List<string>();
private object lock = new object();
public void Add(string str)
{
 lock(lock) list.Add(str);
}

and
private List<string> list  = new List<string>();
public void Add(string str)
{
 lock(list) list.Add(str);
}

2. Why set an lockerObjects as readonly? What does that accomplish?

Are there any other guidelines to consider when using lock?

[1] -http://msdn.microsoft.com/en-us/library/c5kehkcz.aspx

Thanks for the feedback.