Many, many lock races

[Linas Vepstas]

I'm now going through guile-1.8.5 code, and see the potential
for races  leading to deadlocks in many dozens of places.

What I's seeing is lots of this:

scm_i_scm_pthread_mutex_lock(some_lock)
do_something()
scm_i_pthread_mutex_unlock(some_lock)

With the current set of #defines, this turns into the following

pthread_mutex_unlock(thread->heap_mutex); // leave guile
pthead_mutex_lock(some_lock)
pthread_mutex_lock(thead->heap_mutex) // enter guile
do_something()
pthread_mutex_unlock(some_lock)

The above is very clearly badly nested, and leads to a race
with garbage collection, resulting in a deadlock.  I hope this
is "obvious" to the reader: ... right? ... but, to be clear, consider
the following:

thread A:
pthread_mutex_unlock(thread->heap_mutex);  // leave guile
pthead_mutex_lock(some_lock)
pthread_mutex_lock(thread->heap_mutex) { //enter guile
   sleep, since thread C just grabbed this heap_mutex

thread B:
in guile mode (i.e. its own heap_mutex is held)
sleeping on some_lock, which A is holding.

thread C:
scm_i_gc() {
   scm_i_thread_put_to_sleep() {
         scm_i_pthread_mutex_lock (thread A)
         scm_i_pthread_mutex_lock (thread B) {
              sleep, since thread B is already holding it.

and so A is waiting on C is waiting on B is waiting on A ...

I'm planning on going through all of these instances on a
case-by-case basis, but there seems to be many dozens
of these, and this will result in many dozens of patches.

Suggestions?

--linas