This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Critical Sections in GUILE


On Wed, 5 Jul 2000, NIIBE Yutaka wrote:

> The model of thread execution is like follows:
> [...]
> 
>    (3) When a thread goes outside the interpreter and doesn't care
>        about GC, the thread needs to know other threads that it won't
>        cooperate the GC synchronization.
> 
>        The section is surrounded by (say) SCM_OUTSIDE_INTERP_START and
>        SCM_OUTSIDE_INTERP_END.  Synchronization of GC doesn't wait for
>        such threads.  Example is a thread which calls `read' system
>        call, or select system call.  Another example is a thread which
>        enters long loop of calculation.

Another problem are threads that are waiting for some mutex.  With your
approach, such threads will have to surround the attempt to get a mutex
with SCM_OUTSIDE_INTERP_START SCM_OUTSIDE_INTERP_END, or better this would
be part of the mutex locking function.  Another thing that should be
remembered is that SCM_OUTSIDE_INTERP_START and SCM_OUTSIDE_INTERP_END
should nest.

The conservative gc, however, still has to scan the stacks of such
threads.  What if during gc such a thread leaves the
SCM_OUTSIDE_INTERP_END section?  What if during gc such a thread
terminates and its stack space is returned to the system?  Maybe all this
is easily solved, but currently the problem of threads that don't come
across the synchronization point for a long time seems difficult to me.

Best regards
Dirk


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]