[concurrency-interest] Exposing self-references in constructors

Ryan LeCompte Ryan.LeCompte at pango.com
Wed Dec 20 20:05:01 EST 2006

In this case thread B has already been created and executed (start()). So basically what happens is inside of the class's constructor (Executed by thread A), a reference to the instance (this) is passed to a new object that is constructed. This intermediate object (which contains a reference to the class instantiated by thead a) will later be "processed" by thread b (which has already been start()'ed). Sorry if I'm not doing a great job of explaining the situation. Here are the steps again:
1) Thread A (main thread) has been started.
2) Thread A (main thread) instantiates class Foo.
3) In Foo's constructor, it creates a new object (Bar) which contains a reference to Foo (Foo passes "this" to Bar in Foo's constructor).
    Also, not sure if it matters, but I have a single volatile variable that is assigned a value before Bar is instantiated.
4) At a later point (30 seconds, for example), Thread B (which has already been started before Foo is instantiated) operates on the Bar instance and uses the reference to Foo that it contains.
    To be specific in this step, it first synchronize()'s on the "Foo" instance that Bar has a reference to.
Hope this helps clarify the situation.
Ryan LeCompte +1.508.626.8900 x227
      mobile +1.781.249.4009
         fax +1.508.626.8901

PanGo Networks, Inc.


From: David Holmes [mailto:dcholmes at optusnet.com.au]
Sent: Wed 12/20/2006 6:41 PM
To: Ryan LeCompte; concurrency-interest at cs.oswego.edu
Subject: RE: [concurrency-interest] Exposing self-references in constructors

When you say thread B is "later executed" do you mean start() is called later? and by the thread that constructed A? There is a happens-before relationship between the start() of a thread and the first action of that thread.
Otherwise it all depends on the exact call sequence and what threads are involved. 
There are a number of implicit synchronization actions that occur when creating and starting threads that could impose the right happens-before relationships - eg. synchronization when adding to the thread group.
David Holmes

	-----Original Message-----
	From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Ryan LeCompte
	Sent: Thursday, 21 December 2006 8:44 AM
	To: concurrency-interest at cs.oswego.edu
	Subject: [concurrency-interest] Exposing self-references in constructors
	Hello all,
	Here is a scenario:
	- In Thread A's constructor, a reference to "this" is passed along which ultimately ends up stored as a reference in Thread B.
	- Thread A's constructor completes and is fully instantiated.
	- Thread B then is later executed (let's say restrained at 30 seconds later) -- and then uses the reference to Thread A that it was given in Thread A's constructor.
	Is it possible that Thread B's reference to Thread A could be "stale" ? I'm not seeing that this is the case. I know that it's bad practice to hand off references to yourself before you are fully constructed, but in this paticular case I'd like to know if I'm "safe" if I have external time constraints that force Thread B to not read its reference to Thread A until a later time when Thread A has finished fully instantiating.
	Also, what if Thread B is already executing and just operates on a an object instance that contains the reference stored in Thread A's constructor? Consider a scheduling framework where a  pool of threads are already instantiated and running, and simply periodically execute "work instances" that contain the logic to be executed. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20061220/69c77c0c/attachment.html 

More information about the Concurrency-interest mailing list