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

[Jim Rogers <jimmaureenrogers@worldnet.att.net>]

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