From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,LOTS_OF_MONEY, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,15edb893ef79e231 X-Google-Attributes: gidfac41,public X-Google-Thread: f4fd2,23202754c9ce78dd X-Google-Attributes: gidf4fd2,public X-Google-Thread: 103376,15edb893ef79e231 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,15edb893ef79e231 X-Google-Attributes: gid114809,public X-Google-ArrivalTime: 2002-02-11 12:13:33 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!sn-xit-01!sn-xit-03!supernews.com!pd2nf1so.cg.shawcable.net!residential.shaw.ca!news2.calgary.shaw.ca.POSTED!not-for-mail From: kaz@accton.shaw.ca (Kaz Kylheku) Newsgroups: comp.lang.lisp,comp.lang.ada,comp.lang.eiffel,comp.lang.smalltalk Subject: Re: True faiths ( was Re: The true faith ) References: <3C4DE336.3080102@worldnet.att.net> Organization: Psycho-Neurotic Institute for the Very, Very Nervous Reply-To: kaz@ashi.footprints.net User-Agent: slrn/0.9.6.3 (Linux) Message-ID: Date: Mon, 11 Feb 2002 20:13:31 GMT NNTP-Posting-Host: 24.69.255.206 X-Complaints-To: abuse@shaw.ca X-Trace: news2.calgary.shaw.ca 1013458411 24.69.255.206 (Mon, 11 Feb 2002 13:13:31 MST) NNTP-Posting-Date: Mon, 11 Feb 2002 13:13:31 MST Xref: archiver1.google.com comp.lang.lisp:26269 comp.lang.ada:19885 comp.lang.eiffel:5658 comp.lang.smalltalk:19492 Date: 2002-02-11T20:13:31+00:00 List-Id: In article , David Combs wrote: >In article , >AG 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.