You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@reef.apache.org by "Anupam (JIRA)" <ji...@apache.org> on 2015/08/28 22:34:46 UTC
[jira] [Commented] (REEF-657) Race condition in
StreamingCodecFunctionCache in REEF.Network
[ https://issues.apache.org/jira/browse/REEF-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14720519#comment-14720519 ]
Anupam commented on REEF-657:
-----------------------------
I am slightly confused about the fix.
Multiple calls to WriteAsyncFunc/ReadAsyncFunc for same MessageType can possibly still enter AddCodecFunction, which at first glance doesn't seem desirable. What am I missing?
> Race condition in StreamingCodecFunctionCache in REEF.Network
> -------------------------------------------------------------
>
> Key: REEF-657
> URL: https://issues.apache.org/jira/browse/REEF-657
> Project: REEF
> Issue Type: Bug
> Components: REEF.NET
> Environment: C#
> Reporter: Dhruv Mahajan
> Assignee: Dhruv Mahajan
> Fix For: 0.13
>
>
> StreamingCodecCache is not thread safe. As a result there is a race condition that happens when we receive simultaneous message from two streams and we try add codecs in cache.
> The aim of this jira is to make AddCodec function threadsafe by making it atomic by using lock.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [jira] [Commented] (REEF-657) Race condition in
StreamingCodecFunctionCache in REEF.Network
Posted by Anupam <an...@gmail.com>.
Please bear with me as I am trying to understand:
var codec = _injector.GetInstance(codecType);
This is the code that needs the lock?
On 28 August 2015 at 17:53, Dhruv Mahajan <dh...@gmail.com> wrote:
> Overwriting is not an issue. Basically Injector is not thread safe and when
> I try to get instance it needs to be atomic. That's what was giving me
> error and I introduced locks.
>
> Dhruv
> On Aug 28, 2015 4:18 PM, "Anupam" <an...@gmail.com> wrote:
>
> > It can still get overwritten. But it will not corrupt any data structure
> > anymore. I guess that is fine. Given that is the case, I wonder what is
> the
> > purpose of the lock at all.
> >
> >
> >
> > On 28 August 2015 at 13:45, Dhruv Mahajan <dh...@gmail.com>
> wrote:
> >
> > > I have placed the lock just at the starting of AddCodec function.
> > >
> > > dhruv
> > >
> > > On Fri, Aug 28, 2015 at 1:34 PM, Anupam (JIRA) <ji...@apache.org>
> wrote:
> > >
> > > >
> > > > [
> > > >
> > >
> >
> https://issues.apache.org/jira/browse/REEF-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14720519#comment-14720519
> > > > ]
> > > >
> > > > Anupam commented on REEF-657:
> > > > -----------------------------
> > > >
> > > > I am slightly confused about the fix.
> > > > Multiple calls to WriteAsyncFunc/ReadAsyncFunc for same MessageType
> can
> > > > possibly still enter AddCodecFunction, which at first glance doesn't
> > seem
> > > > desirable. What am I missing?
> > > >
> > > > > Race condition in StreamingCodecFunctionCache in REEF.Network
> > > > > -------------------------------------------------------------
> > > > >
> > > > > Key: REEF-657
> > > > > URL:
> https://issues.apache.org/jira/browse/REEF-657
> > > > > Project: REEF
> > > > > Issue Type: Bug
> > > > > Components: REEF.NET
> > > > > Environment: C#
> > > > > Reporter: Dhruv Mahajan
> > > > > Assignee: Dhruv Mahajan
> > > > > Fix For: 0.13
> > > > >
> > > > >
> > > > > StreamingCodecCache is not thread safe. As a result there is a race
> > > > condition that happens when we receive simultaneous message from two
> > > > streams and we try add codecs in cache.
> > > > > The aim of this jira is to make AddCodec function threadsafe by
> > making
> > > > it atomic by using lock.
> > > >
> > > >
> > > >
> > > > --
> > > > This message was sent by Atlassian JIRA
> > > > (v6.3.4#6332)
> > > >
> > >
> >
> >
> >
> > --
> > Anupam
> > Bellevue, WA
> > Ph: +1 (425)-777-5570
> >
>
--
Anupam
Bellevue, WA
Ph: +1 (425)-777-5570
Re: [jira] [Commented] (REEF-657) Race condition in
StreamingCodecFunctionCache in REEF.Network
Posted by Dhruv Mahajan <dh...@gmail.com>.
Overwriting is not an issue. Basically Injector is not thread safe and when
I try to get instance it needs to be atomic. That's what was giving me
error and I introduced locks.
Dhruv
On Aug 28, 2015 4:18 PM, "Anupam" <an...@gmail.com> wrote:
> It can still get overwritten. But it will not corrupt any data structure
> anymore. I guess that is fine. Given that is the case, I wonder what is the
> purpose of the lock at all.
>
>
>
> On 28 August 2015 at 13:45, Dhruv Mahajan <dh...@gmail.com> wrote:
>
> > I have placed the lock just at the starting of AddCodec function.
> >
> > dhruv
> >
> > On Fri, Aug 28, 2015 at 1:34 PM, Anupam (JIRA) <ji...@apache.org> wrote:
> >
> > >
> > > [
> > >
> >
> https://issues.apache.org/jira/browse/REEF-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14720519#comment-14720519
> > > ]
> > >
> > > Anupam commented on REEF-657:
> > > -----------------------------
> > >
> > > I am slightly confused about the fix.
> > > Multiple calls to WriteAsyncFunc/ReadAsyncFunc for same MessageType can
> > > possibly still enter AddCodecFunction, which at first glance doesn't
> seem
> > > desirable. What am I missing?
> > >
> > > > Race condition in StreamingCodecFunctionCache in REEF.Network
> > > > -------------------------------------------------------------
> > > >
> > > > Key: REEF-657
> > > > URL: https://issues.apache.org/jira/browse/REEF-657
> > > > Project: REEF
> > > > Issue Type: Bug
> > > > Components: REEF.NET
> > > > Environment: C#
> > > > Reporter: Dhruv Mahajan
> > > > Assignee: Dhruv Mahajan
> > > > Fix For: 0.13
> > > >
> > > >
> > > > StreamingCodecCache is not thread safe. As a result there is a race
> > > condition that happens when we receive simultaneous message from two
> > > streams and we try add codecs in cache.
> > > > The aim of this jira is to make AddCodec function threadsafe by
> making
> > > it atomic by using lock.
> > >
> > >
> > >
> > > --
> > > This message was sent by Atlassian JIRA
> > > (v6.3.4#6332)
> > >
> >
>
>
>
> --
> Anupam
> Bellevue, WA
> Ph: +1 (425)-777-5570
>
Re: [jira] [Commented] (REEF-657) Race condition in
StreamingCodecFunctionCache in REEF.Network
Posted by Anupam <an...@gmail.com>.
It can still get overwritten. But it will not corrupt any data structure
anymore. I guess that is fine. Given that is the case, I wonder what is the
purpose of the lock at all.
On 28 August 2015 at 13:45, Dhruv Mahajan <dh...@gmail.com> wrote:
> I have placed the lock just at the starting of AddCodec function.
>
> dhruv
>
> On Fri, Aug 28, 2015 at 1:34 PM, Anupam (JIRA) <ji...@apache.org> wrote:
>
> >
> > [
> >
> https://issues.apache.org/jira/browse/REEF-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14720519#comment-14720519
> > ]
> >
> > Anupam commented on REEF-657:
> > -----------------------------
> >
> > I am slightly confused about the fix.
> > Multiple calls to WriteAsyncFunc/ReadAsyncFunc for same MessageType can
> > possibly still enter AddCodecFunction, which at first glance doesn't seem
> > desirable. What am I missing?
> >
> > > Race condition in StreamingCodecFunctionCache in REEF.Network
> > > -------------------------------------------------------------
> > >
> > > Key: REEF-657
> > > URL: https://issues.apache.org/jira/browse/REEF-657
> > > Project: REEF
> > > Issue Type: Bug
> > > Components: REEF.NET
> > > Environment: C#
> > > Reporter: Dhruv Mahajan
> > > Assignee: Dhruv Mahajan
> > > Fix For: 0.13
> > >
> > >
> > > StreamingCodecCache is not thread safe. As a result there is a race
> > condition that happens when we receive simultaneous message from two
> > streams and we try add codecs in cache.
> > > The aim of this jira is to make AddCodec function threadsafe by making
> > it atomic by using lock.
> >
> >
> >
> > --
> > This message was sent by Atlassian JIRA
> > (v6.3.4#6332)
> >
>
--
Anupam
Bellevue, WA
Ph: +1 (425)-777-5570
Re: [jira] [Commented] (REEF-657) Race condition in
StreamingCodecFunctionCache in REEF.Network
Posted by Dhruv Mahajan <dh...@gmail.com>.
I have placed the lock just at the starting of AddCodec function.
dhruv
On Fri, Aug 28, 2015 at 1:34 PM, Anupam (JIRA) <ji...@apache.org> wrote:
>
> [
> https://issues.apache.org/jira/browse/REEF-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14720519#comment-14720519
> ]
>
> Anupam commented on REEF-657:
> -----------------------------
>
> I am slightly confused about the fix.
> Multiple calls to WriteAsyncFunc/ReadAsyncFunc for same MessageType can
> possibly still enter AddCodecFunction, which at first glance doesn't seem
> desirable. What am I missing?
>
> > Race condition in StreamingCodecFunctionCache in REEF.Network
> > -------------------------------------------------------------
> >
> > Key: REEF-657
> > URL: https://issues.apache.org/jira/browse/REEF-657
> > Project: REEF
> > Issue Type: Bug
> > Components: REEF.NET
> > Environment: C#
> > Reporter: Dhruv Mahajan
> > Assignee: Dhruv Mahajan
> > Fix For: 0.13
> >
> >
> > StreamingCodecCache is not thread safe. As a result there is a race
> condition that happens when we receive simultaneous message from two
> streams and we try add codecs in cache.
> > The aim of this jira is to make AddCodec function threadsafe by making
> it atomic by using lock.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>