Re: Race condition in threading code?

["Julian Graham" <joolean@gmail.com>]

Hi Ludovic,

> Let me rephrase it: what can happen is that, during the tick, another
> thread could actually take M, increase `M->level' and mark itself as the
> owner.  After the tick, our primary thread takes `M->lock' back,
> thinking it now owns M, and goes to sleep; but M is actually already
> taken by that other thread, so our primary thread never wakes up.  (Not
> sure this description is any clearer...)

Almost, but not quite.  Let me try again:

Thread A wants to lock fat_mutex M.  It seizes the administrative lock
M->lock and examines the state of M.  M is held by thread B, so thread
A prepares to put itself onto the blocking queue for M by calling
`SCM_TICK'.  In order to call `SCM_TICK', thread A must temporarily
release M->lock.

When it does this, thread B, the owner of M, seizes M->lock and
releases M, which involves waking up the next waiting thread on the
blocking queue for M -- but thread A hasn't finished doing the tick
and so isn't on the blocking queue.  Thread B releases M->lock and
goes about its business.

Thread A finishes the tick and seizes M->lock again and adds itself to
the blocking queue for M without re-examining M's state.  The only way
thread A can ever wake up after this is if another thread locks and
releases M.


> I guess it can be applied to 1.8 as well?

I would say so, yes.  I'll make a patch against it if you tell me how
to do that with git.  :)


> Another question: why is there this mixture of `scm_i_pthread' and
> `scm_i_scm_pthread' calls?

The scm_i_pthread_* functions are actually preprocessor #defines that
map directly onto pthreads API functions.  The scm_i_scm_pthread_*
functions are wrappers around pthreads functions that could block --
the wrappers leave Guile mode before calling into pthreads.
pthread_mutex_lock can block, so from Guile mode (e.g., from
fat_mutex_lock), it needs to be called via
scm_i_scm_pthread_mutex_lock; but pthread_mutex_unlock can't block, so
it can be called directly via scm_i_pthread_mutex_unlock.

Is that what you were asking?


Regards,
Julian