-2

Raleted to:

Lock in static methods

lock Statement

please consider this code:

public static class SomeClass
{
    public static void Method1(string key, int item)
    {
        //Some Work
    }

    public static DataTable Method2()
    {
        //Some Work
    } 

....

If I want to use this class in Asp.Net application from performance point of view does it need separate lock object for every methods like this:

public static class SomeClass
{
    private Object thisLock1 = new Object();  
    public static void Method1(string key, int item)
    {
        lock(thisLock1)
        {
            //Some Work
        }
    }

    private Object thisLock2 = new Object();
    public static DataTable Method2()
    {
        lock(thisLock2)
        {
            //Some Work
        }
    } 

....
Arian
  • 12,793
  • 66
  • 176
  • 300
  • If this is supposed to be thread-safe, you should never return the actual `Items` collection. Once it's returned, the collection can be modified while the caller is using it. If you must return all items, return a copy of the collection instead. And yes, that copy operation would have to be locked. – itsme86 Dec 22 '17 at 15:47
  • 1
    Or, you know, use a [thread safe collection](https://learn.microsoft.com/en-us/dotnet/standard/collections/thread-safe/)... – DavidG Dec 22 '17 at 15:47
  • And instead of having a `key` property in your `Item` class, use a `Dictionary` (or rather a `ConcurrentDictionary`) – DavidG Dec 22 '17 at 15:52
  • 1
    Ideally, write static methods so that they can be safely called by multiple callers. Since all you're showing is, effectively, the signature, the techniques to use cannot be supplied. Writing every static method so that it, effectively, serializes access to the method is generally *not* a good plan. If you *are* going to employ locking, it's also important to know *how separate methods interact*, which we also cannot divine from this question. Short answer: Don't believe you can learn/apply generic "always do X" rules to achieve **acceptable** performance. – Damien_The_Unbeliever Dec 22 '17 at 16:24
  • 1
    I don't think very broad edited version can be answered better than "use a lock at the appropriate / chosen granularity" provided in what I believe is duplicate - https://stackoverflow.com/questions/5053172/why-does-the-lock-object-have-to-be-static. – Alexei Levenkov Dec 22 '17 at 16:29
  • Or to put it yet another way - if there was a *universally correct* way of writing this code, I would hope that it would be *built into* the CLR. – Damien_The_Unbeliever Dec 22 '17 at 16:40

2 Answers2

2

Is lock object deparatly necessary for every static methods

NO, and NO

consider this case

You have another method called RemoveFromCache and it uses lock3

lock3 on thread 1
ItemRemove Iteration Start
lock1 on thread 2
Item Removed
thread1 Iterator.Next

Exception on thread1 due to collection modified. Anyone can get an instance of the collection with GetAllItems method. It is hard to enforce thread safety with your private lock. You should consider using one of those thread safe collection instead.

Steve
  • 11,696
  • 7
  • 43
  • 81
  • Thanks, and if there is not a shared property (here `Items`) is it necessary? – Arian Dec 22 '17 at 16:11
  • its never necessary, but if the operations are isolated then its more efficient to use separate locks – Steve Dec 22 '17 at 16:12
  • I updated my question – Arian Dec 22 '17 at 16:14
  • @Arian it is really case by case situation here. Depending what your somework is you may not even need the lock. Or you need to use the same lock in some but not the others – Steve Dec 22 '17 at 16:17
2

You don't HAVE to lock the object when you try to access it, but it's highly recommended.

If you don't want to perform these locks yourself, Microsoft added a class that's thread safe, it's the ConcurrentBag Class, it's great because this logic is already implemented, so you can access and remove it from several threads or classes.

However, locks give you a finer control over list access. Check this link for examples of bag implementation.

RedNet
  • 416
  • 5
  • 12