[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Race condition in threading code?
From: |
Julian Graham |
Subject: |
Re: Race condition in threading code? |
Date: |
Sun, 31 Aug 2008 11:05:17 -0400 |
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
- Re: Race condition in threading code?, (continued)
- Re: Race condition in threading code?, Han-Wen Nienhuys, 2008/08/26
- 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 <=
- 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?, Han-Wen Nienhuys, 2008/08/31
- Re: Race condition in threading code?, Han-Wen Nienhuys, 2008/08/31