rspec/rules/S2222/comments-and-links.adoc

=== On 2014-11-21T15:07:44Z Freddy Mallet Wrote:
My 2 cents [~ann.campbell.2]:

* tag "multi-threading" is missing
* moreover the main purpose of the rule is the following one: as soon as Enter() and Exit() statements are not called in the same method, fully understanding when those methods are really called at run time might be tricky, that's why we advise as a good practice to locate them in the same method. So for me, this rule more relates to a maintainability issue. 

=== On 2014-11-24T14:07:22Z Ann Campbell Wrote:
\[~freddy.mallet] when Enter() and Exit are not called in the same method, there's no guarantee that they're both called.

=== On 2014-11-25T10:23:33Z Freddy Mallet Wrote:
\[~ann.campbell.2] the code might be perfectly designed to be sure that method Enter() and Exit() are called as expected even when they are not located in the same method. But our rule engine is not smart enough to figure out when this is the case or not. That's why for me this rule relates to a coding best practice because by definition is they are not located in the same methods and even if the code is perfectly correct, this will require an extra effort for a developer to inject a change. 

=== On 2015-04-01T17:47:33Z Ann Campbell Wrote:
To follow up on this conversation, I've added a case (try/catch/finally) to this method & reverted SQALE to Reliability/Synchronization

=== On 2015-05-11T11:38:11Z Dinesh Bolkensteyn Wrote:
\[~ann.campbell.2] If we are anyway enforcing that the ``++Monitor.Enter()++`` and ``++Monitor.Exit()++`` calls should be done from the same method, then why not simply ban the direct usage of the ``++Monitor++`` class and force the usage ``++lock (...) {}++`` directives instead?


http://stackoverflow.com/questions/4978850/monitor-vs-lock

=== On 2015-05-21T13:45:47Z Ann Campbell Wrote:
\[~dinesh.bolkensteyn] I don't really understand how this SO post is an argument for that.

=== On 2015-05-22T12:51:00Z Dinesh Bolkensteyn Wrote:
Well [~ann.campbell.2] I fail to see this why you would want to write the compliant solution:


----
class MyClass {
  object lock = new object();

  public void DoTheThing() {
    try {
      Monitor.Enter(lock);
      // ...
    } catch (ExceptionType e) {
      //...
    } finally {
      Monitor.Exit(lock);
    }
}
----

instead of the much simpler:


----
class MyClass {
  object lock = new object();

  public void DoTheThing() {
    lock (lock)
    {
    }
}
----

=== On 2015-05-22T13:01:31Z Tamas Vajk Wrote:
\[~ann.campbell.2] I agree with [~dinesh.bolkensteyn]  on this one. The ``++lock++`` block is equivalent to the following:

----
bool lockWasTaken = false;
var temp = obj;
try
{
    Monitor.Enter(temp, ref lockWasTaken);
    { body }
}
finally
{
    if (lockWasTaken) Monitor.Exit(temp);
}
----

So why not use the language construct if there is one for exactly this?

=== On 2015-05-22T14:36:53Z Ann Campbell Wrote:
Are we talking about a new rule or a change to the recommendation in this one?

=== On 2015-05-22T15:04:17Z Tamas Vajk Wrote:
\[~ann.campbell.2] I would just change the recommended solution. And update the description saying that the easiest way of achieving the aim is to use the ``++lock++`` statement.


BTW the message and the descriptions seems to go after different things, and that is causing the confusion here. [~dinesh.bolkensteyn]?

=== On 2015-05-22T18:49:21Z Ann Campbell Wrote:
\[~tamas.vajk] and [~dinesh.bolkensteyn] I've updated the description and compliant example. I've also moved the messages up from the Java subtask. See if they suit you better.

=== On 2015-05-26T10:07:59Z Tamas Vajk Wrote:
Looks good.

=== On 2015-05-27T08:19:20Z Dinesh Bolkensteyn Wrote:
This RSPEC was initially created to re-implement a Gendarme rule: DoNotUseLockedRegionOutsideMethodRule

=== On 2015-05-29T14:26:30Z Dinesh Bolkensteyn Wrote:
http://www.mono-project.com/docs/tools+libraries/tools/gendarme/rules/concurrency/#donotuselockedregionoutsidemethodrule

=== On 2015-06-01T08:16:25Z Dinesh Bolkensteyn Wrote:
\[~ann.campbell.2] Please review the description

=== On 2015-06-01T17:30:08Z Ann Campbell Wrote:
looks good [~dinesh.bolkensteyn]. Thanks.

=== On 2015-06-11T18:41:25Z Ann Campbell Wrote:
CodePro: Call Lock Without Unlock