Related articles |
---|
[9 earlier articles] |
Re: Adding garbage collection to C++ tmb@idiap.ch (1992-08-17) |
Re: Adding garbage collection to C++ tmb@idiap.ch (1992-08-17) |
Re: Adding garbage collection to C++ hudson@cs.umass.edu (1992-08-17) |
Re: Adding garbage collection to C++ fjh@munta.cs.mu.OZ.AU (1992-08-18) |
Re: Adding garbage collection to C++ tmb@arolla.idiap.ch (1992-08-18) |
Re: Adding garbage collection to C++ tmb@arolla.idiap.ch (1992-08-19) |
Re: Adding garbage collection to C++ maxtal@extro.ucc.su.OZ.AU (1992-08-20) |
Re: Adding garbage collection to C++ fjh@munta.cs.mu.OZ.AU (1992-08-21) |
Newsgroups: | comp.compilers |
From: | maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) |
Organization: | MAXTAL P/L C/- University Computing Centre, Sydney |
Date: | Thu, 20 Aug 1992 23:41:50 GMT |
References: | 92-08-092 92-08-093 |
Keywords: | C, GC, parallel |
>[How do you garbage collect multi-threaded programs where some pointers to
>shared memory are kept in per-thread private storage]
Clearly you have to GC at the level of sharing. If A and B share
storage, you have to make the collector scan the stacks of both A and B.
So the collector needs to be implemented in the Operating system.
Perhaps simply retaining a pointer in the address space of A works
for threads, but it doesnt work for systems like Windows, where you 'give
away' the pointer to the OS. There IS no stack or local address space
between callbacks into you're program, so there is nowhere to retain that
pointer.
--
JOHN (MAX) SKALLER, maxtal@extro.ucc.su.oz.au
Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.