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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham 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-01-22 15:47:52 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!newsfeed.direct.ca!look.ca!wn1feed!worldnet.att.net!135.173.83.71!wnfilter1!worldnet-localpost!bgtnsc04-news.ops.worldnet.att.net.POSTED!not-for-mail Message-ID: <3C4DFA24.4020107@worldnet.att.net> From: Jim Rogers User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 22 Jan 2002 23:47:51 GMT NNTP-Posting-Host: 12.86.35.197 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc04-news.ops.worldnet.att.net 1011743271 12.86.35.197 (Tue, 22 Jan 2002 23:47:51 GMT) NNTP-Posting-Date: Tue, 22 Jan 2002 23:47:51 GMT Organization: AT&T Worldnet Xref: archiver1.google.com comp.lang.lisp:25015 comp.lang.ada:19206 comp.lang.eiffel:5504 comp.lang.smalltalk:18487 Date: 2002-01-22T23:47:51+00:00 List-Id: Kaz Kylheku wrote: > 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! > Of course Doh! I was thinking about the concept of many handles to the same object, without the object state itself identifying the "owner". > >>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. > Aha. There are solutions to this problem, with or without GC. The solution is to provide a separate storage pool for each thread. That storage pool could then be managed manually or by GC. With this design, one thread consuming its storage pool would not interfere with the storage usage of other threads. If you do use GC you will need some way of partitioning the GC work among the storage pools. This could be done in a single GC, or by implementing many GC's. > >>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. > Yes, I know this. It appears to me that computing unreachability across a multi-processor system is much more difficult than with the simpler memory model of a uni-processor system. Am I wrong? > 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. Yes, and that concurrent sharing complicates the reachability algorithm. While operations on general shared memory objects do not need to be, and indeed often cannot be, atomic, operations on semaphores must be atomic. This includes reachability calculations. It would seem that an object that is unreachable must remain unreachable. In general this is true. With out of order instruction execution in some multi-processor systems this cannot be guaranteed. > > 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. > Certainly, a GC properly implemented for a multithreaded environment should be just as easy to use as one implemented in a single threaded environment. This does, however, argue for a language providing GC to also implement a threading model as part of the language standard. Mixing a threaded implementation with a GC designed only for single threaded applications could lead to very disappointing results. Jim Rogers Colorado Springs, Colorado USA