[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Race condition in threading code?
From: |
Ludovic Courtès |
Subject: |
Re: Race condition in threading code? |
Date: |
Sun, 31 Aug 2008 21:39:19 +0200 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) |
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'.
- Re: Race condition in threading code?, (continued)
- Re: Race condition in threading code?, Han-Wen Nienhuys, 2008/08/27
- Re: Race condition in threading code?, Ludovic Courtès, 2008/08/27
- Re: Race condition in threading code?, Julian Graham, 2008/08/27
- Re: Race condition in threading code?, Julian Graham, 2008/08/30
- Re: Race condition in threading code?, Han-Wen Nienhuys, 2008/08/30
- Re: Race condition in threading code?, Julian Graham, 2008/08/30
- Re: Race condition in threading code?, Han-Wen Nienhuys, 2008/08/31
- Re: Race condition in threading code?, Ludovic Courtès, 2008/08/31
- Re: Race condition in threading code?, Ludovic Courtès, 2008/08/31
- Re: Race condition in threading code?, Julian Graham, 2008/08/31
- Re: Race condition in threading code?,
Ludovic Courtès <=
- Re: Race condition in threading code?, Ludovic Courtès, 2008/08/31
- Re: Race condition in threading code?, Han-Wen Nienhuys, 2008/08/31
- Re: Race condition in threading code?, Han-Wen Nienhuys, 2008/08/31