You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kylin.apache.org by "Ted Yu (JIRA)" <ji...@apache.org> on 2017/09/16 15:31:00 UTC

[jira] [Commented] (KYLIN-2874) Ineffective check in CubeDesc#getInitialCuboidScheduler

    [ https://issues.apache.org/jira/browse/KYLIN-2874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16168955#comment-16168955 ] 

Ted Yu commented on KYLIN-2874:
-------------------------------

Similar problem can occur in CubeSegment#getAdvisor()

> Ineffective check in CubeDesc#getInitialCuboidScheduler
> -------------------------------------------------------
>
>                 Key: KYLIN-2874
>                 URL: https://issues.apache.org/jira/browse/KYLIN-2874
>             Project: Kylin
>          Issue Type: Bug
>            Reporter: Ted Yu
>
> {code}
>     public CuboidScheduler getInitialCuboidScheduler() {
>         if (cuboidScheduler != null)
>             return cuboidScheduler;
>         synchronized (this) {
>             if (cuboidScheduler == null) {
>                 cuboidScheduler = CuboidScheduler.getInstance(this);
>             }
> {code}
> Suppose thread 1 obtains the lock and modifies cuboidScheduler.
> This modification can be re-ordered with other correlated field assignments within this critical section at runtime. Thus, checking the value of cuboidScheduler is not an effective test that the critical section has completed unless the guarding lock is held while checking.
> When cuboidScheduler is assigned a newly constructed value, the JVM is allowed to reorder the assignment of the new reference to cuboidScheduler before any field assignments that may occur in the constructor.
> If thread 2 comes and read cuboidScheduler, it may use partially initialized object.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)