>At 1:54 PM -0700 4/24/98, Ken Dickey wrote:
>
>>GC can be done at first by stopping all (non-gc) threads.  This works to
>>get things up.
>
>Then you violate real time that the original poster was after.

Agreed.  I was thinking of staged ways to get the above up and running 
incrementally.  I guess when it comes from implementing stuff I just do 
better doing it in stages and having a working system at each stage.  
(Hey, it works for me.  ;^)


>>Then you can go to a concurrent collector (too big to
>>discuss here).
>
>Do you have a line on a real time concurrent GC that is really
>real time? (Some algorithms have been claimed to be real time
>which aren't.)

I would suggest looking at Springer Lecture Notes 637 and 986 
(International Workshop In Memory Management '92 and '95) as well as Paul 
Wilson's survey.  There are a bunch of papers with various assumption 
sets.  I agree that many so called real-time collectors aren't. The 
implementation of Baker's Treadmill by Wade Hennesy used in Kaleida's 
ScriptX multi-media runtime is real-time.  It really depends on what 
trade-offs you want to make.  It really is too detailed a discussion for 
a quick answer.


>>  Also, if you have a 2-word compare&swap, you can do 'lockless'
>>  concurrent queueing (check a newer OS textbook for algorithms).

>This seems neat. This is kind of like a "linear object" providing
>unique (solitary) access?
>
>Do you have a good OS textbook you recommend, Ken?

I originally learned about 'lockless queueing' reading about the 
Synthesis kernel, which has some really cool ideas, including 
specialization by runtime code generation.

Henry Massalin "Synthesis: An Efficient Implementation of Fundamental 
Operating System Services", Columbia U Ph.D. Thesis, 1992.

I have not bought any OS books lately, but note that compare&swap 
techniques are covered in Gray & Reuter's "Transaction Processing, 
Concepts and Techniques" (Morgan Kaufmann 1993) which you probably have 
gathering dust on your bookshelf, Patrick.  8^)


Cheers,
-Ken