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

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

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.