using this as synchronization object - C# Discussion Boards

Re: Searching System Drive for a file

22-Mar-08 4:18

You might want to look at DirectoryInfo and FileInfo classes.

Upcoming FREE developer events:
* Developer Day Scotland

Recent blog posts:
* Mixins in C#3.0

My website | Blog

MNFlyer22-Mar-08 4:19

MNFlyer

22-Mar-08 4:19

Does the following work?

Requires System.IO namespace

foreach (string FileName in Directory.GetFiles(path, "file.ext"))
{

}

using this as synchronization object

George_George22-Mar-08 3:52

Re: using this as synchronization object [modified]

22-Mar-08 3:52

Hello everyone,

As mentioned in this article, why using this or type itself as lock object is bad idea? What means "it potentially offers public scope to the synchronization object"?

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

I quote the whole paragraph below,

--------------------
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");
      ...

A dedicated field is commonly used (such as locker, in the example prior), because it allows precise control over the scope and granularity of the lock. Using the object or type itself as a synchronization object, i.e.:

lock (this) { ... }
or:

lock (typeof (Widget)) { ... }    // For protecting access to statics

is discouraged because it potentially offers public scope to the synchronization object.
--------------------

thanks in advance,
George

girm22-Mar-08 4:01

girm

22-Mar-08 4:01

Hi,

The class of 'this' (say NotPrivateClass) might not be private (or might not be private anymore in the future) , so let's say that someone else could do :

NotPrivateClass x=new NotPrivateClass();<br />
lock(x)

in another thread and therefore create a potential deadlock with

//this = x<br />
lock (this) { ... }

hope it helps

modified on Saturday, March 22, 2008 10:09 AM

George_George22-Mar-08 4:03

22-Mar-08 4:03

Thanks girm,

What means "offers public scope" and why it is discouraged?

regards,
George

Colin Angus Mackay22-Mar-08 4:09

22-Mar-08 4:09

public scope means it is available outside of the class itself.

In the context of synchronisation objects it is discouraged. If the sync' object is available outside of the class other code can attempt to lock it - this could potentially lead to a deadlock.

Upcoming FREE developer events:
* Developer Day Scotland

Recent blog posts:
* Mixins in C#3.0

My website | Blog

George_George23-Mar-08 2:53

23-Mar-08 2:53

Thanks Colin,

Colin Angus Mackay wrote:
this could potentially lead to a deadlock.

Could you describe a scenario why expose this as lock object will cause deadlock compared with using private object as lock please?

regards,
George

girm22-Mar-08 4:09

girm

22-Mar-08 4:09

well, in my exemple NotPrivateClass , has potentially a public scope : some other class could access it

consider 'this' is an instance of NotPrivateClass (in the code you quoted) : someone else could access to the instance refercenced by this ("public scope is offered").

so if you use 'this' as the locking object , then someone else could do the same .. and that's not ggod .. for the deadlock reason I've given

George_George23-Mar-08 2:54

23-Mar-08 2:54

Thanks girm,

Could you describe a scenario why expose this as lock object will cause deadlock compared with using private object as lock please?

regards,
George

girm24-Mar-08 8:19

girm

24-Mar-08 8:19

Sure...

public class PublicClass1
{
   public PublicClass1(){};
   public void LockMe1(PublicClass2 aPublicInstance2)
   {
     lock(this) // ref line (X)
     {
         lock(aPublicInstance2)
         {
            MessageBox.ShowDialog("no deadlock, great!!");
         }
     }
}

public class PublicClass2
{
   public PublicClass2(){};
}

...
say a thread Y calls :

// aPublicInstance2 is an object of PublicClass2
// aPublicInstance1 is an object of PublicClass1
lock(aPublicInstance2) // ref line (Y)
{
   lock(aPublicInstance1)
   {
       MessageBox.ShowDialog("no deadlock, great!!");
   }
}

another thread X calls :

aPublicInstance1.LockMe1(aPublicInstance2); // aPublicInstancex is the same object as in thread Y

Lets say that thread X is actually executing '// ref line (X)'
and thread Y is actually executing '// ref line (Y)'
...no problem...

then X step forward and is now stuck because it cannot acquire the lock :
lock(aPublicInstance2) , since it is already locked by thread Y

But Y is still running and perform a call :
...and then is stuck because it cannot acquire lock on aPublicInstance1 (see 'lock(aPublicInstance1)
') because it is locked by thread X (see lock(this) // ref line (X))

...so X is blocking Y, Y is blocking X : deadlock , no message is displayed

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

Now if locked object were not publicly availlable X and Y thread would not have been able to
put lock on those objects since they wouldn't have access to it.
...
of course simply not using 'lock(this)' will not garantee you will never have deadlocks : it just limit the risks

regards
Girm

George_George24-Mar-08 19:01

24-Mar-08 19:01

Wonderful sample, cool Grim!

regards,
George

Colin Angus Mackay22-Mar-08 4:06

22-Mar-08 4:06

If you are using the keyword "this" then most likely something elsewhere has access to that object, the thing that called the method you are in will have a reference to what ever "this" is, for example.

If you want to ensure that the object is threadsafe then exposing the thing you are using to lock (synchronise) isn't a good idea as code you have no control over could attempt to do the same thing by locking the object. If that happens, I'd imagine that it becomes easier to get into a situation where deadlocks can occur. A deadlock is where two bits of code are blocked because the first is waiting for the second to complete, and vice versa. In this scenario neither will complete.

So, if the object uses private objects internally to do the locking then nothing else can access the synchonisation objects and you have better control over how the locking works, and if you do find yourself in a situation where a deadlock occurs you won't have far to look to track down the problem (it will all be in one class).

Upcoming FREE developer events:
* Developer Day Scotland

Recent blog posts:
* Mixins in C#3.0

My website | Blog

George_George23-Mar-08 2:51

23-Mar-08 2:51

Thanks Colin,

I read your reply carefully. Agree and understand most of your points. Just one question,

Colin Angus Mackay wrote:
If that happens, I'd imagine that it becomes easier to get into a situation where deadlocks can occur.

Why using internal private object as lock object will reduce chance of deadlock compared with using this object? Could you describe a scenario please?

regards,
George

Colin Angus Mackay23-Mar-08 4:06

23-Mar-08 4:06

George_George wrote:
Why using internal private object as lock object will reduce chance of deadlock compared with using this object? Could you describe a scenario please?

Well, if you use a private object then nothing outside the class can access the object. That means that you have full control within the class of how instances of the class are synchronised.

If you use "this", and other code uses the reference to the same object then they can interfere with each other. There isn't much you can do to defend yourself from code that you have not written and have no control over.

Upcoming FREE developer events:
* Developer Day Scotland

Recent blog posts:
* Mixins in C#3.0

My website | Blog

George_George23-Mar-08 4:17