Re: Race condition in threading code?

[Ludovic Courtès]

Hey!

"Julian Graham" <address@hidden> writes:

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

Thanks for the clarification, that's what I was trying to express.  ;-)

I just pushed it to `master'.

>> 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.  :)

The easiest way is to "cherry-pick" the change.  So, assuming the commit
is at the tip of `master', you'd do:

  $ git checkout branch_release-1-8
  $ git cherry-pick master

  ... resolve conflicts...

  $ git commit -a -c THE-ID-THAT-GIT-TOLD-YOU-BEFORE

And that's it!

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

Yes, exactly.  I had overlooked this.

Thanks!

Ludo'.