[
https://issues.apache.org/jira/browse/IGNITE-4684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054099#comment-16054099
]
Alexander Menshikov commented on IGNITE-4684:
---------------------------------------------
More information about IgniteCacheProcessProxy:
The IgniteCacheProcessProxy#get() calls for the IgniteCompute#call(), which
calls for the IgniteComputeImpl#callAsync0() which has guard()/unguard() pair
with readlock.
Inside guard()/unguard() pair there is line:
*ctx*.*closure*().callAsync(BALANCE, job, *prj*.nodes(), *execName*)
I used bold for marking a reading shared fields. The #closure() is simple
getter.
The field ctx can be final. Fields closure, prj and execName can be volatile.
In fact, they are written only once.
There is a busy lock inside #callAsync(). So it keeps saving all operation
inside. But method still possible to read ctx fields under a race.
So inside #callAsync() there are 2 operations with ctx:
1) ctx.task().setThreadContext(TC_SUBGRID, nodes); // Will look thread safety
if we make GridKernalContextImpl.taskProc volatile.
2) ctx.task().execute(new T7<>(mode, job), null, sys, execName); // Maybe still
need guard()/unguard() pair in execute() method, but maybe not.
> Local cache.get(K) should not block
> -----------------------------------
>
> Key: IGNITE-4684
> URL: https://issues.apache.org/jira/browse/IGNITE-4684
> Project: Ignite
> Issue Type: Improvement
> Components: cache
> Reporter: Yakov Zhdanov
> Fix For: 2.1
>
>
> Currently there is synchronized section on desired cache entry which cause
> problems on multithreaded access
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
