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, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f4fd2,23202754c9ce78dd X-Google-Attributes: gidf4fd2,public X-Google-Thread: fac41,15edb893ef79e231 X-Google-Attributes: gidfac41,public X-Google-Thread: 114809,15edb893ef79e231 X-Google-Attributes: gid114809,public X-Google-Thread: 103376,15edb893ef79e231 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-01-22 14:55:24 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!lnsnews.lns.cornell.edu!news.litech.org!news-feed.riddles.org.uk!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: <%njZ7.279$iR.150960@news3.calgary.shaw.ca> <3c36fbc5_10@news.newsgroups.com> <4idg3u40ermnp682n6igc5gudp7hajkea9@4ax.com> <76be8851.0201101909.9db0718@posting.google.com> <9jtu3u8cq92b05j47uat3412tok6hqu1ki@4ax.com> <3C3F8689.377A9F0F@brising.com> <3219936759616091@naggum.net> <3C483CE7.D61D1BF@removeme.gst.com> <7302e4fa4a.simonwillcocks@RiscPC.enterprise.net> <3C4D9B03.60803@mail.com> <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: Tue, 22 Jan 2002 22:54:08 GMT NNTP-Posting-Host: 24.69.255.206 X-Complaints-To: abuse@shaw.ca X-Trace: news2.calgary.shaw.ca 1011740048 24.69.255.206 (Tue, 22 Jan 2002 15:54:08 MST) NNTP-Posting-Date: Tue, 22 Jan 2002 15:54:08 MST Xref: archiver1.google.com comp.lang.lisp:25011 comp.lang.ada:19203 comp.lang.eiffel:5502 comp.lang.smalltalk:18483 Date: 2002-01-22T22:54:08+00:00 List-Id: In article <3C4DE336.3080102@worldnet.att.net>, Jim Rogers 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. > >Copying pointers and using GC or even reference counting is a very >nice solution for single threaded applications. It becomes a very >messy solution for multi-threaded applications. Now all those >copied pointers need to be protected from inappropriate simultaneous >access by several threads. By definition, something that is copied isn't shared, and so doesn't have to be protected. What it points to is shared, so that's a different matter. Making copies of every object is not a realistic solution in multithreaded programs, no matter what language they are written in. You can do it sometimes, but not always. If you must share references to objects, GC is far cleaner and safer than reference counting techniques. It will automatically ensure that no thread will delete an object while it is still in use by another thread. >In threaded applications GC solves no concurrency issues, but it >does complicate them. How can a semaphore be "held" by only one >thread if only one instance exists, and all threads hold a >pointer to that instance? How can a semaphore be useful unless there is one shared instance of it? Do you know the first thing about threading? Doh! >How can you keep one thread from >consuming all the free store or "heap"? This is a problem regardless of your memory management strategy, if you admit dynamic storage allocation. If you insist on making copies for the sake of avoiding sharing, you will only make this concern worse. Garbage collection eliminates memory leaks, thus lessening the concern. >Obviously there are answers to all those questions. >Unfortunately, those answers a generally pretty messy unless >someone has designed your GC solution with concurrency in mind. Do you know what GC is? It simply means computing what objects are unreachable and liberating their storage for future allocations. It has nothing to do with the semantics of those objects while they are still live. Garbage collected or not, shared objects have to be protected from concurrent access. Of course a garbage collector has to be correctly implemented to be used in a multithreaded environment. However, it remains easy to use; the user simply remains unconcerned about what happens to unreachable objects.