guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Let's throw out SCM_NEWCELL


From: Dirk Herrmann
Subject: Re: Let's throw out SCM_NEWCELL
Date: Fri, 7 Sep 2001 02:50:37 +0200 (MEST)

On 7 Sep 2001, Marius Vollmer wrote:

> I propose to change the current practice so that no half initialized
> cell is ever seen by the GC.  scm_gc_mark would abort on seeing a free
> cell, and scm_mark_locations (and scm_gc_mark_cell_conservatively if
> will survive) would not mark a free cell, even if the pointer points
> to a valid cell.  scm_gc_sweep would continue to ignore free cells.

I was the one who added scm_gc_mark_cell_conservatively (blush).  I added
it under the assumption, that a gc can happen _any_ time due to multi
threading.  If, however, we go the way that gc can only happen if all
threads are gone to sleep or are known to be in some state where they
won't disturb and won't be disturbed by gc, there would probably be no
need for scm_gc_mark_cell_conservatively.  This would then also fix the
bug that you have described.

The reason that I have had problems with the idea that all but one thread
should go asleep during gc is, that I had no idea how this could be
realized:  What about threads that are waiting for a mutex?  What about
threads that are waiting for input?  However, in the meantime I have an
idea how this could be solved:  Threads that may enter a blocked state
should before indicate so, say, by setting some bit telling "I'm off for
vacation.  Don't wait for me."  That is, before calling a function that
may block the thread and before locking a mutex, each thread enters
holiday mode.  Immediately after a mutex is obtained, the thread clears
the holiday flag and then checks whether it should go asleep.  Similarly,
after a function which might block the thread has returned, the holiday
flag is cleared and the thread checks whether it should go asleep.  The
important thing is, that no scheme objects are created or referenced 
during the holidays and that at the end of the holidays the thread checks
whether it should go asleep.

Sorry for the long explanation, and maybe all this has been obvious for
those who have been suggesting the 'all threads go asleep' idea.  However,
it wasn't for me, and probably there are still some problems that are not
covered yet with the above scheme - but at least I feel better believing
that we can, even with posix threads, make sure gc only happens at some
defined points.

> To ensure that initialization can not be interrupted by a GC, we
> provide new functions/macros to allocate a cell that include
> initialization.  For example

The bad thing about this is, that there are some places where you first
need to have the uninitialized cell before you know about the
initialization values.  Further, some initializations work incrementally,
like first setting the upper bits of cell_word_1 with some macro, then
setting the lower bits etc.  That is, trying to provide a ready-to-go pair
of cell_word_1 and cell_word_0 will not generally lead to a cleaner
initialization.  However, without scm_gc_mark_cell_conservatively there
shouldn't be the need to apply such a patch.

What we should do, however, is to generate a set of C test cases that
intentionally create stack frames which point into certain critical
positions of the heap and then call the gc.

Best regards
Dirk Herrmann




reply via email to

[Prev in Thread] Current Thread [Next in Thread]