Re: srfi-18 requirements

[Neil Jerram]

"Julian Graham" <address@hidden> writes:

> Hi Neil,

Hello again!  I've added some comments below, but I think that for the
last few emails we've rather lost sight of the ball - mostly my fault,
for pursuing details that didn't need pursuing.  So actually my
comments below are not really important.

Looking back, and clawing our way back towards SRFI-18 (remember that
:-), I suggest that

- I'll stop raising unproven issues in the threads code!

- we apply the generic / bug fix patch that you already posted, except
  without the extra thread_admin_mutex locking (which I think we
  concluded we can't justify) - that will be to HEAD

- I'll have a go at devising a test for the critical section in
  make_jmpbuf bug; if I succeed, I'll run the test on 1.8.x too, and
  port the fix over

- you continue on the C enhancements and Scheme code for SRFI-18, as
  already discussed and agreed

- once all of your code and tests are in (HEAD), we can see if there
  are any _actual_ generic thread code issues that we need to address,
  and address them.

What do you think?

> Ignoring... (but is that what all_threads is for?  My understanding
> was that it was for ALL threads created by / initialized to use Guile
> -- i.e., all threads that needed to be GC'd.)

(I'm not sure, but I think that (i) a thread that has left guile mode
ain't gonna call SCM_TICK, and (ii) the fact that all threads need to
be GC'd is handled by the thread saving its stack top and flushing its
registers in suspend().  But in any case, we should leave this until
someone writes a cunning test case to expose it.)

> I don't think this is possible -- the GC thread could never have
> gotten to that point unless it had locked the non-GC thread's
> heap_mutex.  By the time it sets wake_up_flag to 1, it must also be
> holding the wake_up_mutex, which means that the non-GC thread had
> already relinquished it via the cond_wait.

Yes, agreed now.  (Note that this does rely on the overlapping, and so
this is the "hard reason".)

> I think that they do (need to overlap).  And I'm having a hard time
> seeing the potential for deadlock here (maybe I'm just sluggish from
> the heat in my cubicle).  I think the order of locking is critical to
> preventing deadlock, in fact, via a race on wake_up_flag.  In the
> situation you describe, the non-GC thread will only be able to seize
> wake_up_mutex once the wake_up_flag has been set and the GC thread has
> permanently relinquished wake_up_mutex for that round of collection,
> so there's no deadlock.  Am I missing something?

No, you're very likely right.  I think from here on the onus should be
on me (or anyone else) to come up with an actual test, instead of
trying to argue theoretically.

(And for the same reason, I don't think we should apply your new code
to CVS yet, because I don't think we've yet demonstrated an actual
problem with the existing code - is that right?)

Regards,
        Neil