Github user JoshRosen commented on the pull request:
https://github.com/apache/spark/pull/2028#issuecomment-52589813
Regarding the first synchronized in that constructor, my understanding is
that the original `TorrentBroadcast.synchronized` was guarding the writing of
the broadcast value to the BlockManager. I think that this synchronization is
unnecessary _not_ because we don't leak `this`, but because BlockManager is
thread-safe and the uniqueness of broadcast ids means that we'll never have
parallel attempts to write the same block.
My point was that _multiple TorrentBroadcast objects_ can be simultaneously
under construction, but that it's safe because they'll have distinct ids; I
think preventing leakage of a partially-constructed object is a separate issue
that doesn't come into play here.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
