This is the mail archive of the guile@sources.redhat.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]

Critical Sections in GUILE


OK, I'm back.  I'd like to introduce POSIX Threads support in Guile.

The model of thread execution is like follows:

   (1) There's a main thread which handles UNIX signal.
       Signal handler is called only by this thread.

   (2) There's a synchronization point (or points) for GC.  Say, at eval.
       All the threads are synchronized here, and only one thread can
       enter GC.

   (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.

   (4) The potion of the code should be protected so that concurrent
       execution (which is not necessarily means parallel) doesn't
       mess up the things.  We call it critical section.

Now, I'd like to talk about the implementation of critical section in
Guile.

In the current implementation, it is implemented by SCM_DEFER_INTS and
SCM_ALLOW_INTS.  It seems that it's designed for the protection
against UNIX signal, then, (ab)used for the (non-parallel) thread.

The codes with SCM_DEFER_INTS/SCM_ALLOW_INTS would be the candidates
for critical sections for thread implementation.  Besides, we need to
protoct more, for example, the part of accessing hash table or any
other resources.

			*	*	*

As a first step of my challenge, I don't think I'll change the code
with SCM_DEFER_INTS/SCM_ALLOW_INTS.  I'll continue to use them with
the meaning of "critical section for thread" although the name doesn't
match.

There are many places where allocation is done within the
SCM_DEFER_INTS/SCM_ALLOW_INTS.  I'd like to tidy up such codes
so that allocation is done outside the pair.   This is the first step, 
this doesn't have any impact to the Guile, I think.

Any opinion are appreciated.
-- 

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