You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Anand Mazumdar (JIRA)" <ji...@apache.org> on 2016/07/29 01:03:20 UTC

[jira] [Created] (MESOS-5926) Using the scheduler library as a member variable might lead to race conditions.

Anand Mazumdar created MESOS-5926:
-------------------------------------

             Summary: Using the scheduler library as a member variable might lead to race conditions.
                 Key: MESOS-5926
                 URL: https://issues.apache.org/jira/browse/MESOS-5926
             Project: Mesos
          Issue Type: Bug
            Reporter: Anand Mazumdar


Currently, it's possible to have a couple of possible race conditions if using the scheduler library as a member variable in a non-libprocess class.

{code}
class Foo
{
  Foo() : mesos(...) {}

  void connected() {}
};
{code}

It's possible that the scheduler library "thread" might invoke the connected callback before the object is fully constructed (context switch) or lead to two threads accessing the {{Foo}} class.

Another alternative pattern that can trigger this is:
{code}
class Foo
{
  Foo()
  {
    mesos.reset(new Mesos(...));
  }

  void connected()
  {
    mesos->send(...);
  }
private:
  Mesos mesos;
};
{code}

It's possible that {{mesos.reset(...)}} was never executed due to a context switch. The {{connected}} callback might get invoked by another thread that invoked {{mesos->send(...)}} but {{Mesos}} hasn't been {{reset}} yet.

A possible way to fix this would be to expose a {{start()}} method similar to the driver implementation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)