Lock statement in threading C#

Question

1.00/5 (1 vote)

See more:

Hi Experts,
Can you please help me to find the answer of below questions.

1)What is the role of synobject in lock statement?

C#

public class lockherper
   {
       private static object synobj=new object();

       public void MyCriticalData()
       {
           //What is role of this synobj?
           lock (synobj)
           {
             //Critical section
           }
       }
   }

2)Can we use value type as synobject?.If yes, then what are side effect of taking value type in synobject.

C#

public class lockherper
   {
       private static int  synobj=new int();

       public void MyCriticalData()
       {
           //can we use value type as synobject?side effect of this?
           lock ((object)synobj)
           {
             //Critical section
           }
       }
   }

Thanks
Dinesh Sharma

What I have tried:

Can you please help me to find the answer of below questions.

1)What is the role of synobject in lock statement?

C#

public class lockherper
   {
       private static object synobj=new object();

       public void MyCriticalData()
       {
           //What is role of this synobj?
           lock (synobj)
           {
             //Critical section
           }
       }
   }

2)Can we use value type as synobject?.If yes, then what are side effect of taking value type in synobject.

C#

public class lockherper
   {
       private static int  synobj=new int();

       public void MyCriticalData()
       {
           //can we use value type as synobject?side effect of this?
           lock ((object)synobj)
           {
             //Critical section
           }
       }
   }

Thanks
Dinesh Sharma

Posted 7-Jun-16 12:57pm

Er. Dinesh Sharma

Updated 7-Jun-16 14:07pm

Add a Solution

Comments

Sergey Alexandrovich Kryukov 7-Jun-16 21:22pm

The question is very good, but your post is probably not. Where did you get these questions? Did you invent them yourself, or someone gave them to you? Is it your homework?

Anyway, it's no good to use the section "What I have done" this way. If you done nothing, say that you've done nothing.

—SA

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Garth J Lancaster · Answer 1 · 2016-06-07T13:44:00

Solution 1

I think you'd be better off going to somewhere like Threading in C# - Free E-book[^] and read the material there - there's a great chapter on synchronization & locking

Posted 7-Jun-16 13:44pm

Garth J Lancaster

Updated 7-Jun-16 13:45pm

Comments

Sergey Alexandrovich Kryukov 7-Jun-16 20:22pm

The book looks good to me, but it does not answer the second question; and that question is the only one that count, not a trivial one. (Please see Solution 2.)
—SA

Sergey Alexandrovich Kryukov · Answer 2 · 2016-06-07T14:07:00

First of all, it's important to understand what locks do: the lock statement serves as a facility for mutually exclusive execution of some fragment of code. Usually, this fragment of code is used to access shared objects or other shared resources, but this is just the typical use, not the rule. Please see: Mutual exclusion — Wikipedia, the free encyclopedia.

But now, fragments of code "protected" by lock with different lock objects are not considered as mutually exclusive. Only if the lock objects are different, two different thread execute the same fragment of code, of different fragment of code "protected" with the lock with the same lock objects are synchronized. If lock objects are different, the "locked" fragment of code can be executed by two or more thread in parallel; threads are not delayed at the lock.

Note that this MSDN documentation page explains that lock operation is precisely equivalent to System.Threading.Monitor operation: 8.12 The lock statement (C#).

See, see also: Monitor Class (System.Threading).
This is a really tricky question.

First of all, the trick is based on the concept of boxing: Boxing and Unboxing (C# Programming Guide).

Let's consider this code fragment:

C#
```
int a = 1;
int b = 1;
bool saveValues = a == b; // true;
bool sameObjects = (object)a == (object)b; // false
bool isEqual = a.Equals(b); // true
bool referentiallyTheSame = object.ReferenceEquals(a, b); // false
```
If at least one of the comparison results is not quite clear, you need to learn all those cases and understand how they work. In particular, you need to understand that virtual methods of System.Object can be overridden and that, with such methods, we deal with boxed representation of the value type, which is, technically, the reference type.

In this sense, the type of the synchronous class will always be the reference type. But the question remains: can the technique shown in the question be used? The answer is: no. In each lock statement, new object will be created, and that object will be different each time. In other words, no two threads would be waiting for each other on the critical section fragment of code, which would be logically equivalent of having no lock. Note that the actual boxed object is created on stack, and each thread has its own stack (this is the main feature of threading) and, hence will be not shared.

The real idea behind the lock object is: it should be shared by all thread competing for the resource "protected" be the lock, and it should be not publicly accessible: lock Statement (C# Reference).

If we created the boxed object (accessed by reference) from some numeric value (or any other value-type value) just once and shared this reference between all thread, the locking would work, but doing so is pointless.

It's logically natural that the locking mechanism uses the referential identity of the lock object. Using the value semantic would not make any sense for this purpose; it can be modified by overriding System.Object.Equals(object); and calling this method by the locking mechanism would be pointless, from both the semantic point of view, and also from the performance standpoint. For locking to work, the lock objects should be referentially identical. But I also checked it up experimentally. In this case, this is a firm proof. If the parallel execution of a critical section wasn't detected, it would not proof anything, but it's easy to see that the execution of two threads is interlacing, in general case. That is, the locking mechanism using the boxed object created on stack cannot work. Please try:

C#
```
class ThreadWrapper {
    internal ThreadWrapper(int id) {
        thread = new Thread(Body);
        this.id = id;
    } //internal ThreadWrapper
    internal void Start() {
        thread.Start();
    }
    internal void Join() {
        thread.Join();
    }
    int id;
    const int lockInt = 1;
    void Body() {
        lock ((object)lockInt) {
            for (int count = 0; count < 100; ++count)
                System.Console.WriteLine("{0}: {1}", id, count);
        } //lock
    } //Body
    Thread thread;
} //class ThreadWrapper 

class Program {
    static void Main(string[] args)  {
        ThreadWrapper w1 = new ThreadWrapper(1);
        ThreadWrapper w2 = new ThreadWrapper(99999999);
        w1.Start();
        w2.Start();
        w1.Join();
        w2.Join();
        System.Console.WriteLine("Press any key...");
        System.Console.ReadKey(true);
    } //Main
} //Program
```

—SA