Using variable or using direct method call

[-]

If I were to do this:

public void method() {
Container parent = getParent();

:::
:::

:::

parent.callMethod(...);

:::
:::

:::
:::

parent.callAnotherMethod(...);


:::
:::
}


and if another thread were to change the parent, will the above fail
since the method is not synchronized?

Or should I just leave it that way rather than change it to
getParent().callMethod(...) everytime...but doing so is of no use since
if the parent changes midway, the method's objective will not be met
since it requires that the parent be the same throughout the method's scope?

 

[P.Hill]

If I were to do this:

public void method() {
Container parent = getParent(); [...]

parent.callMethod(...);

[...]

parent.callAnotherMethod(...);

}


and if another thread were to change the parent, will the above fail
since the method is not synchronized?

Another thread can't change the LOCAL variable which references parent,
because locals are on the stack of each thread.

Now, if "Container parent" was a member, then we'd be talking about
a problem.

On the other hand, there could be thread problems if:
1. two threads called callMethod() both of which change the
members of parent.

2. callMethod() and callAnotherMethod() were expecting the state of the
members of parent to be stable between these two calls,

In either case you have a problem.

One solution for (1) is to synchronize callMethod() and callAnotherMethod().

One solution for (2) might be

synchronized ( parent ) {
parent.callMethod(...);
[...]
parent.callAnotherMethod(...);
}

But if there is anything to do between the calls which involves
any other synchronized objects you have deadlock potential.

-Paul

 

[Johan Poppe]

and if another thread were to change the parent, will the above fail
since the method is not synchronized?

Or should I just leave it that way rather than change it to
getParent().callMethod(...) everytime...

Depends on what you want and what you consider "fail".

Basically, you are talking about a situation where the locally stored
'parent' and the result of getParent() is no longer the same. That
means that
parent.callAnotherMethod()
and
getParent().callAnotherMethod()
will call on different objects. The first variant will call on the
container that was the parent when the method started. The second
variant will call on the container that is the parent right now. I
can't tell you which of the objects you _want_ to call on.

but doing so is of no use since
if the parent changes midway, the method's objective will not be met
since it requires that the parent be the same throughout the method's scope?

If you want to call on the same container object throughout your
method, _and_ you want that object to be the actual parent-container,
then you should synchronize on something.

 

[Thomas G. Marshall]

P.Hill coughed up:

If I were to do this:

public void method() {
Container parent = getParent(); [...]

parent.callMethod(...);

[...]

parent.callAnotherMethod(...);

}


and if another thread were to change the parent, will the above fail
since the method is not synchronized?

Another thread can't change the LOCAL variable which references
parent, because locals are on the stack of each thread.

Now, if "Container parent" was a member, then we'd be talking about
a problem.

What are you talking about? The parent object was returned by a getParent()
method and could possibly be publicly accessible. That object is able to be
mutated at any time! No one is worried about the "parent" variable itself.


....[rip]...

 

[P.Hill]

No one is worried about the "parent" variable itself.

The OP did not make that clear, so I thought to mention it.

Depends on what you want and what you consider "fail".

-Paul