synchronization object choosing

[George2]

Hello everyone,


What means "the synchronizing object can double as the object it's protecting" in below statements about synchronization object choosing?

I quote the whole paragraph,

http://www.albahari.com/threading/part2.html

--------------------
Choosing the Synchronization Object
Any object visible to each of the partaking threads can be used as a synchronizing object, subject to one hard rule: it must be a reference type. It’s also highly recommended that the synchronizing object be privately scoped to the class (i.e. a private instance field) to prevent an unintentional interaction from external code locking the same object. Subject to these rules, the synchronizing object can double as the object it's protecting, such as with the list field below:


class ThreadSafe {
List <string> list = new List <string>();

void Test() {
lock (list) {
list.Add ("Item 1");
...

--------------------


thanks in advance,
George

[mariocatch]

George, you've posted numerous questions on these forums. Each question relates to the prevoius question. If you can't understand concept A, and concept B requires you to know Concept A first, then you should not continue reading until you fully understand concept A.

You're just going to be digging yourself deeper until you get lost and give up.

[George2]

Sorry for any inconvenience, mariocatch!


I am new, but I like practice and love C# programming from beginning. I have make some study, but I am very confused about what means "double as the object it's protecting".

Any ideas? Any drawbacks if we use the list object as lock object?

George, you've posted numerous questions on these forums. Each question relates to the prevoius question. If you can't understand concept A, and concept B requires you to know Concept A first, then you should not continue reading until you fully understand concept A.

You're just going to be digging yourself deeper until you get lost and give up.


regards,
George

[darwen]

Do you know what 'lock' does George ?

Darwen.

[Mutant_Fruit]

Any ideas? Any drawbacks if we use the list object as lock object?


The only drawback is that something else might be using the list as a synchronising object. For example if you use a third party library and decide to use one of its objects as your 'lock object', you could create a deadlock if the library also uses the same object as its 'lock object'.

You should only lock on stuff you are 100% sure nothing else is using as its 'lock object'. The easy way to create an object which is safe to use as a 'lock object' is to just instantiate an 'object':


object listLocker = new object();


then, whenever you want to protect access to your list, you can write:

lock (listLocker)
{
// Do list stuff here
}

[George2]

Thanks Darwen,


Sure. I am previously Java developer and I would like to pick-up my skills for .Net. Learn from you. :-)

Do you know what 'lock' does George ?

Darwen.


regards,
George

[George2]

Thanks Mutant_Fruit,


I do not quite understand this scenario. Why deadlock? Could you provide some pseudo code please or more description?

For example if you use a third party library and decide to use one of its objects as your 'lock object', you could create a deadlock if the library also uses the same object as its 'lock object'.



regards,
George

[Mutant_Fruit]

The first and second links on this should explain it well enough:

http://www.google.ie/search?hl=en&q=threading+deadlock&btnG=Google+Search&meta=

[George2]

Thanks Mutant_Fruit,


The two links are both about what is deadlock, but not what I am confusing about. What I am confused is why using this object compared with using private data member as lock will be more prone to cause deadlock? Could you describe a scenario please? :-)

The first and second links on this should explain it well enough:

http://www.google.ie/search?hl=en&q=threading+deadlock&btnG=Google+Search&meta=


regards,
George

[darwen]

OK George, let's try to explain here.

Consider this class :


public class Class1
{
private List<int> _list1 = new List<int>();
private List<int> _list2 = new List<int>();

public void Method(int value)
{
lock (_list2)
{
lock (_list1)
{
_list1.Add(value);
_list2.Add(value);
}
}
}

public List<int> List1
{
get
{
return _list1;
}
}

public List<int> List2
{
get
{
return _list2;
}
}
}


Let's also consider an external method in another thread :


public void OtherThreadMethod(Class1 instance)
{
lock (instance.List1)
{
lock (instance.List2)
{
Console.WriteLine("{0} {1}", instance.List1.Count, instance.List2.Count");
}
}
}


This will produce deadlock if one thread calls Class1.Method and another thread calls 'OtherThreadMethod' on the same instance of Class1. This is because the order that the lists are 'locked' are different in both cases.

This is what the passage is trying to avoid : you should always use instances of objects private to a class to perform any locks in methods inside the class. Then you can't have a deadlock situation.

Darwen.

[George2]

Thanks Darwen,


Cool sample. Question answered.

OK George, let's try to explain here.

Consider this class :


public class Class1
{
private List<int> _list1 = new List<int>();
private List<int> _list2 = new List<int>();

public void Method(int value)
{
lock (_list2)
{
lock (_list1)
{
_list1.Add(value);
_list2.Add(value);
}
}
}

public List<int> List1
{
get
{
return _list1;
}
}

public List<int> List2
{
get
{
return _list2;
}
}
}


Let's also consider an external method in another thread :


public void OtherThreadMethod(Class1 instance)
{
lock (instance.List1)
{
lock (instance.List2)
{
Console.WriteLine("{0} {1}", instance.List1.Count, instance.List2.Count");
}
}
}


This will produce deadlock if one thread calls Class1.Method and another thread calls 'OtherThreadMethod' on the same instance of Class1. This is because the order that the lists are 'locked' are different in both cases.

This is what the passage is trying to avoid : you should always use instances of objects private to a class to perform any locks in methods inside the class. Then you can't have a deadlock situation.

Darwen.


regards,
George