Re: True faiths ( was Re: The true faith )

[kaz@accton.shaw.ca (Kaz Kylheku)]

In article <a47r79$jf$1@news.panix.com>, David Combs wrote:
>In article <ZUm48.2916$Lv.376063@news.xtra.co.nz>,
>AG <nospam@nowhere.co.nz> wrote:
>>> Bruce Hoult wrote:
>>>
>>> > Garbage collection has a *lot* to do with this problem!
>>> >
>>> > A large proportion of assignments in languages such as C++ are done
>>> > merely in order to resolve the question of who owns an object and who is
>>> > responsible for eventually deleting it.
>>> >
>>> > With GC available, objects are seldom copied with pointers to them being
>>> > passed around instead.  You don't care who "owns" the object, because it
>>> > just magically goes away when all the pointers to it get forgotten.
>>
>>This doesn't seem to be a question of something "going away", it's a
>>question
>>of how the object(s) behave while they are still in use. For example:
>>
>>Suppose you have a process A which has something (an object or whatever)
>>called X it wants to pass to a process B. The process B must be free to do
>>whatever it wants to/with that X thing. However, the process A also wants to
>>keep going with the X after the B is done with whatever it was doing 
>
>Coroutines (across processes) help here?  You do have to
>know (not just when?) but *where*, in the source, you want
>to "resume" the other one.  Not at all "automatic".

Not really, because A and B want to use the object in parallel. Coroutines
make the synchronization problem go away, because coroutine A is suspended
when coroutine B is running and vice versa. The passing of control
is explicit.  With processes you don't have this, except maybe with
non-preemptive (cooperative) threads.

The solutions are to copy the object upfront, or to do some lazy copying:
copy on write. This is what happens with the memory pages of a process
on a moderm Unix system when you do fork(). Otherwise if B destructively
manpulates an object that A is also using, you have an instant race
condition.

Of course, there is the possibility of making a thread-aware object which
can be shared in some disciplined way. 

>NOW we DO have a problem: that call back into the
>first program, the one with memory-mngt via gc,
>just might eat up enough pieces of newly allocated
>memory that it triggers a gc!
>
>Thus pulling the rug out from under the 2nd program --
>since its reference back into the first program's
>data structure will be pointing to garbage, if
>the "shared" data structure gets slid somewhere
>else by the gc.

Firstly, you may be confusing GC with compacting-GC. It's not a
necessity for garbage collection to actually move data around to
eliminate fragmentation. The primary job of garbage collection is to
hunt down unreachable memory and liberate it.  If the GC in question is
non-compacting, you have nothing to worry about, (so long as the non-GC
domain isn't the only one with remaining references to the object, so
that it looks unreferenced in the GC domain).

If objects *can* be moved by the collector, what you can do is implement
the ability to lock some objects to prevent them from moving. Any objects
that are passed into the non-GC domain are locked, and then their
previous lock status is restored upon returning.

Making copies of objects into the non-GC domain, which have to be
liberated there, is also not out of the question. In the reverse
direction, any object created in the non-GC domain that you want to brring
into the GC domain will almost certainly have to be reallocated into
GC storage. The non-GC domain can be equipped with a special function
for allocating GC storage for objects in preparation for passing them
the GC domain, so the copy operation doesn't have to take place.

Since the non-GC domain is probably written in some stone age language
with manual memory allocation, its programmers won't mind learning some
special way of allocating memory. :)

>QUESTION: what kind of solutions are there to
>this problem?
>
>(The one I've been using is to turn off the
>gc during the first call out, and re-activating
>it when that first call returns -- the hope
>being that the 2nd call back in doesn't run
>out of memory!  (Actually, we make it do
>a preemptive gc before we freeze everything.)

This is equivalent to locking down everything, which is simpler, but
unnecessary.