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)