Re: Critical Sections in GUILE

[NIIBE Yutaka <gniibe at chroot dot org>]

Thank you for your comments, Dirk.

Dirk Herrmann wrote:
 > It would IMO be better to use different names, because then it will be
 > obvious which parts of the code have been already changed and reviewed by
 > you.

OK, agreed.  It's better approach.

Dirk Herrmann wrote:
 > 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.

No, I don't think we need this.  I think that we should not introduce
synchronization point here.  If some thread is waiting for mutex, it
means that another thread is holding the mutex and it's in the
critical region.  ... which means we need to wait the thread in
critical region to finish anyway.

 > Another thing that should be remembered is that
 > SCM_OUTSIDE_INTERP_START and SCM_OUTSIDE_INTERP_END should nest.

For now, I don't think so.  Instead, it should not nest, IMHO for now.
Although I'm not sure, it'll work as the __boundary__ between Guile and
external program.  The boundary is... the clearer is the better.

If it nests, it means that it's actually not the boundary between
Guile and external program (it's inside the Guile still), isn't it?

Do you have specific examples where the nesting is needed?

 > 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?

Good points.  We need to handle such cases.
--