[concurrency-interest] Exposing self-references in constructors

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


David,
 
Unfortunately I think the example is a bit too convoluted to try and provide a code skeleton here. I think the main idea here is that a happens-before relationship needs to occur before the other thread actually begins execution/processing on "Bar". I'll look into this further.
 
Thanks,
Ryan

________________________________

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


Ryan,
 
It isn't completely clear to me how the Foo and Bar are "published" such that thread B gets to see them. A code skeleton would help.
 
In practical terms there is no chance that all memory accesses won't have stabilized after thirty seconds. But that isn't the sort of thing one wants to be relying on - if for nothing else than "time" isn't very visible when code is being read by people or processed by tools. :)
 
Cheers,
David

	-----Original Message-----
	From: Ryan LeCompte [mailto:Ryan.LeCompte at pango.com]
	Sent: Thursday, 21 December 2006 11:05 AM
	To: dholmes at ieee.org; concurrency-interest at cs.oswego.edu
	Subject: RE: [concurrency-interest] Exposing self-references in constructors
	
	
	David,
	 
	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
	 
	 
	--
	Ryan LeCompte +1.508.626.8900 x227
	      mobile +1.781.249.4009
	         fax +1.508.626.8901
	
	PanGo Networks, Inc.
	www.pango.com

________________________________

	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.
	 
	Cheers,
	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. 
		 
		Thoughts?
		 
		Thanks
		Ryan
		 

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


More information about the Concurrency-interest mailing list