[concurrency-interest] Exposing self-references in constructors

David Holmes dcholmes at optusnet.com.au
Wed Dec 20 20:16:37 EST 2006


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. :)

  -----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


  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

  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

  Otherwise it all depends on the exact call sequence and what threads are

  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
    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/20061221/f765fb8f/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 1176 bytes
Desc: not available
Url : /pipermail/attachments/20061221/f765fb8f/attachment-0001.bin 

More information about the Concurrency-interest mailing list