Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid incorrect usage of partially-initialized objects in reactors benchmark #360

Merged
merged 3 commits into from
May 22, 2022

Conversation

lbulej
Copy link
Member

@lbulej lbulej commented May 22, 2022

The PingPong and StreamingPingPong sub-benchmarks use an inner class to work around the circular dependency between the ping and pong reactors. However, because reactors execute asynchronously with respect to the main thread and because the communication between the two reactors is started before the inner class is fully initialized, the pong reactor may actually observe an uninitialized reference (inner class instance variable) to the ping reactor (the pong reactor's event handler may start executing before the constructor of the inner class finishes). This is most likely what is going on in #359.

Because the reactor initialization mixes code executed synchronously with lambdas that capture environment but execute asynchronously (event handlers), the ordering of things is not immediately obvious. The commits in this PR separate the reactor setup code from the code that starts the communication and make sure that both happen on the main thread to keep them ordered. In the PingPong-style benchmarks, even though the reference to the inner class instance becomes part of the closure of the event handling lambdas, the communication is started only after the inner class instance is fully initialized, which apparently fixes #359.

Similar changes (to start the communication on the main thread) have been made to the ThreadRing and RoundAbout sub-benchmarks for clarity (no bugs have been reported for those).

The benchmarks use an inner class to work around the circular
dependency between the two reactors in the PingPong-style
benchmarks, but the communication between the two reactors is
started before the inner class is fully initialized.

Because reactors execute asynchronously with respect to the main
thread, the 'pong' reactor may observe/use an unitialized (null)
reference to the 'ping' reactor, because it will start executing
before the constructor of the inner class finishes (issue #359).

This change separates the creation of the two reactors (there is
no need for one to create the other) and even though the inner
class instance reference becomes part of the closure of the event
handling lambdas, the communication is started outside the 'ping'
reactor initializer, i.e., only when inner class instance is fully
initialized.

This apparently fixes #359.
Even though this has not manifested in a problem, it is generally
bad practice to expose object references from constructors. In
this particular case, initiating benchmark message exchange from
a constructor is likely to do just that.

Separating setup phase from the start of the benchmark message
exchange does not hurt anything and makes the code easier to
understand.
The message exchange in the Roundabout benchmark is started by sending
a channel reference to another reactor. We currently do this in the
receiver reactor's body (which is really an initializer executed during
reactor construction).

It is probably OK, but not necessarily obviously correct. The reason is
that we are exposing a reference to the reactor's main channel that a
human reader can reasonably expect to become first visible only after
the return of the `spawn` method.

In absence of detailed documentation on what is or is not allowed in
a reactor body, we should prefer code that is more obviously correct.
Sending the channel reference from outside the reactor body makes it
obvious that the benchmark message exchange is only started after all
reactors are done initializing.
@axel22 axel22 self-requested a review May 22, 2022 17:29
@axel22
Copy link
Member

axel22 commented May 22, 2022

Nice analysis and good catch - yes, it sounds like the this leaking during constructor execution is indeed what's going on here.

Copy link
Member

@axel22 axel22 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@lbulej lbulej merged commit 5da525f into master May 22, 2022
@lbulej lbulej deleted the issue/359 branch May 22, 2022 19:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Transient NullPointerException and deadlock in the reactors benchmark
2 participants