[concurrency-interest] Exposing self-references in constructors

Dhanji R. Prasanna dhanji at gmail.com
Wed Dec 20 19:13:30 EST 2006


30 seconds seems like enough time, but it is not a great way to ensure a
happens-before boundary. Why not start thread B but wait it on a gate until
thread a is done:

class B impls Runnable {

   public Semaphore isReady = new Semaphore(1, true);

   public B(A a) { .. } //ctor

   public void run() {
      isReady.acquire();  //blocks until A is ready
   }
}

class A impls Runnable {
    A() { //ctor
       B b = new B(this);

       b.isReady.acquire();  //takes first lock on B
       new Thread(b).start();  //start B but its now blocked coz we have its
semaphore down

       //finish my init work
       //..

       b.isReady.release();  //raise semaphore--ensures B starts sometime
AFTER now
    }

}


Now whatever B does with its reference to A will be on a completely
constructed/initialized A.
Im sure you could work a similar scenario with j.u.c.Lock.

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?


Not too sure what you mean exactly. Do you mean the work instances will
control thread A's state? Or just work on each other? If the latter, you can
use a similar mutex scenario to the one I described above to prevent
"incomplete" instances from being read/mutated by other threads.

Dhanji.


On 12/21/06, Ryan LeCompte <Ryan.LeCompte at pango.com> wrote:
>
>  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
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20061221/b8efc73c/attachment.html 


More information about the Concurrency-interest mailing list