Hey! "Julian Graham" <[EMAIL PROTECTED]> 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'.