commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MATH-1134) unsafe initialization in BicubicSplineInterpolatingFunction
Date Tue, 01 Jul 2014 17:04:26 GMT

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

Phil Steitz commented on MATH-1134:
-----------------------------------

Yes, we are dealing with cached member data here.  There are four logical options, that I
will list in my personal order of preference

0) Revert the change and just document that the class is not threadsafe.  This sounds wimpy,
but basically the choice is between burdening all users of the class with the overhead associated
with one of the other options or just burdening those who actually want to use instances as
singletons with protecting them themselves.  That is the strategy we have used elsewhere and
it has always made sense to me - users who use math objects that have internal state know
better than us what the concurrency context of their applications are and can eat all and
only the overhead they need to ensure correctness of their code.  We should make it clear
which objects maintain internal state and mark them as not threadsafe, but we should not force
ourselves to precompute everything or forego caching / mutability to maintain threadsafety
everywhere.
1) Protect the cached data by synchronizing access to it (adding sync blocks / explicit locks
where needed)
2) Get rid of the caching - actually compute the partials each time they are requested
3) State of trunk as of r1606940 (force cache preload at construction)

Gilles suggestion to make 3) itself configurable sort of combines 3) and 0) IIUC what he is
suggesting.

> unsafe initialization in BicubicSplineInterpolatingFunction
> -----------------------------------------------------------
>
>                 Key: MATH-1134
>                 URL: https://issues.apache.org/jira/browse/MATH-1134
>             Project: Commons Math
>          Issue Type: Bug
>    Affects Versions: 3.3
>            Reporter: Derek Scherger
>            Priority: Minor
>
> The lazy initialization of the internal array of partialDerivatives in BicubicSplineInterpolatingFunction
is not thread safe. If multiple threads call any of the partialDerivative functions concurrently
one thread may start the initialization and others will see the array is non-null and assume
it is fully initialized. If the internal array of partial derivatives was initialized in the
constructor this would not be a problem.
> i.e. the following check in partialDerivative(which, x, y)
>         if (partialDerivatives == null) {
>             computePartialDerivatives();
>         }
> will start the initialization. However in computePartialDerivatives()
>         partialDerivatives = new BivariateFunction[5][lastI][lastJ];
> makes it appear to other threads as the the initialization has completed when it may
not have.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message