SharedValidationRules and locking in CSLA 3.8.x

SharedValidationRules and locking in CSLA 3.8.x

Old forum URL: forums.lhotka.net/forums/t/11774.aspx


comp1mp posted on Wednesday, January 09, 2013

Hi,

Inspecting the code in SharedValidationRules class I noticed that the synchronization object used in the lock is _managers, the private dictionary which contains the ValidationRulesManager for each Type.

 

    internal static ValidationRulesManager GetManager(Type objectType, bool create)

    {

      ValidationRulesManager result = null;

      if (!_managers.TryGetValue(objectType, out result) && create)

      {

        lock (_managers)

        {

          if (!_managers.TryGetValue(objectType, out result))

          {

            result = new ValidationRulesManager();

            _managers.Add(objectType, result);

          }

        }

      }

      return result;

    }

 I was taught that the synchronization object itself is never blocked, and to always use a private variable of type object declared for the sole purpose of being the synch object.

Seeing the above code made me wonder if I had been taught wrong.

For example, does using _managers as the synch object result in blocking calls to RuleExistsFor?

    public static bool RulesExistFor(Type objectType)

    {

      return _managers.ContainsKey(objectType);

    }

Thanks,

Matthew

RockfordLhotka replied on Monday, January 21, 2013

It is recommended to use a private instance value as the target of the lock statement. Whether that's a real object or a 'new Object()' can vary.

The target object of a lock statement merely defines the scope of the lock. The basic recommendations are there to help people avoid deadlock or race conditions. But if you intentionally want to lock against something in multiple parts of your code then you need to make sure to use a common scope for your lock.

Copyright (c) Marimer LLC