none
AppDomain thread synchronization and sibling access RRS feed

  • Question

  • Three guestions.  Each answer I receive for any one of them I will mark as "the answer."

    First, it seems as if the only way for AppDomain 'B' to obtain a proxy to an object in AppDomain 'C' is if it simultaneously creates an object in 'C' (e.g. CreateInstanceAndUnwrap).  But what if I want 'B' to have a proxy to an *existing* object in 'C'.  Can that be done?

    Second, to handle inter-AppDomain thread synchronization, all literature I've read (Richter, web, etc) suggests use of kernel objects.  I don't see why that is necessary.  Why can't I have several AppDomains accessing several marshalbyrefobjects of type 'X' that are all in AppDomain 'Q', and those 'X' objects are in turn accessing a singleton type 'Y' also in 'Q'?  That singleton could contain a regular monitor lock mechanism.  Why should I  believe that can't work?

    Third, if AppDomain 'A' creates two other AppDomains 'B' and 'C', I presume the easiest way for 'B' to obtain a proxy accessing an object in 'C' is if AppDomain 'A' willingly passes the 'C' AppDomain reference to 'B'.  In other words, 'B' can't obtain the AppDomain reference to 'C' on its own.  Is there any other lightweight solution for 'B' to gain a proxy to an object in 'C' (perhaps without requiring such cooperation from 'A')?
    -Brent Arias
    Thursday, February 12, 2009 7:42 PM

Answers

  • I'll keep it short, the odds of you giving me 3 answer marks are slim.  Objects don't automatically spring to live, it requires code to create them.  If a constructor that runs in another AD creates more than another object, there's no "handle" you could use to reference the second  one.  CIAU only returns one.  IEnumerable jumps to mind as a workaround.

    Locking requires the same object reference to be used in both threads.  You can't get a reference to an object in another AD without marshaling it.  Which turns it into another object.

    I don't see an obvious lighter weight solution, other than keeping a lid on rampant AD creation.

    Hans Passant.
    • Marked as answer by Brent Arias Friday, February 13, 2009 6:29 AM
    Friday, February 13, 2009 1:40 AM
    Moderator

All replies

  • I'll keep it short, the odds of you giving me 3 answer marks are slim.  Objects don't automatically spring to live, it requires code to create them.  If a constructor that runs in another AD creates more than another object, there's no "handle" you could use to reference the second  one.  CIAU only returns one.  IEnumerable jumps to mind as a workaround.

    Locking requires the same object reference to be used in both threads.  You can't get a reference to an object in another AD without marshaling it.  Which turns it into another object.

    I don't see an obvious lighter weight solution, other than keeping a lid on rampant AD creation.

    Hans Passant.
    • Marked as answer by Brent Arias Friday, February 13, 2009 6:29 AM
    Friday, February 13, 2009 1:40 AM
    Moderator
  • My first and second question ultimately deal with the question of a singleton in one AppDomain being accessible by other AppDomains.  Based on my studies, and your answer, I think I cannot *directly* get references to a singleton.  But it still seems obvious to me that I can get references *indirectly* to that singleton, like this:


    AppDomain 'A'
     -has proxy object 'alpha'
    AppDomain 'B'
     -has proxy object 'omega'

    AppDomain 'C'
     -has real object 'alpha'
     -has real object 'omega'
     -both 'alpha' and 'omega' have methods invoking a singleton 'gamma' (e.g. stack based, automatic variables).

    So you see, the AppDomains 'A' and 'B' are indirectly accessing the singleton in AppDomain 'C'.  And that singleton can have a normal 'monitor' lock for thread synchronization.


    -Brent Arias
    • Edited by Brent Arias Friday, February 13, 2009 6:42 AM clarification
    Friday, February 13, 2009 6:39 AM