You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Addison (JIRA)" <ji...@apache.org> on 2018/02/05 22:05:00 UTC

[jira] [Created] (GEODE-4599) Ensure native client checks if locks are acquired

Addison created GEODE-4599:
------------------------------

             Summary: Ensure native client checks if locks are acquired
                 Key: GEODE-4599
                 URL: https://issues.apache.org/jira/browse/GEODE-4599
             Project: Geode
          Issue Type: Wish
          Components: native client
            Reporter: Addison


In several places NC tries to acquire a lock, but never checks that the lock was successfully acquired.  ACE documentation clearly states that this is bad behavior:

{noformat}
Code like this is dangerous:
  {
    ACE_Guard<ACE_Lock> g(lock);
    ... perform critical operation requiring lock to be held...
  }
Instead, one must do something like this:
  {
    ACE_Guard<ACE_Lock> g(lock);
    if (! g.locked())
      {
        ... handle error ...
      }
    else
      {
        ... perform critical operation requiring lock to be held ...
      }
  }
{noformat}

It's worth noting that this may be linked to GEM-267 where the following code was found with an error thrown inside a critical section of {{ThinClientRegion.cpp}}.

{noformat}
if (m_resultCollectorLock != NULL) {
    ACE_Guard < ACE_Recursive_Thread_Mutex > guard(
        *m_resultCollectorLock);
    m_rc->addResult(result);
} else {
    m_rc->addResult(result);
}
{noformat}

We may need to investigate on a case-by-case basis how we should handle when the lock isn't successfully acquired.  There are roughly 200 other places where this same behavior is present.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)