Message5070
Logged In: YES
user_id=246388
I closed it because I thought the thelock->locked variable
will ensure that the PyThread_release_lock will help to
protect the condition variable and I was wrong. The
linuxthread man page on pthread_cond_signal:
A condition variable must always be associated with a
mutex, to avoid the race condition where a thread prepares
to wait on a condition variable and another thread signals
the condition just before the first thread actually waits
on it.
which means you can't call pthread_cond_signal &
pthread_cond_wait on the same condition variable at the
same time. And using a mutex to protect them is a good
idea. Here is how thing might go wrong with current
implementation:
thread 1 thread 2
|int PyThread_acquire_lock _
|/** assume lock was acquired
| by thread 1, hence locked=0
| & success would be 0 **/
|{
| ...
| status = pthread_mutex_lo
| CHECK_STATUS("pthread_mut
| success = thelock->locked
| if (success) thelock->loc
| status = pthread_mutex_un
| /** thread 2 suspended **/
void PyThread_release_lock _|
{ |
... |
status = pthread_mutex_loc|
CHECK_STATUS("pthread_mute|
|
thelock->locked = 0; |
|
status = pthread_mutex_unl|
/** thread 1 suspend **/ |
| CHECK_STATUS("pthread_mut
|
| if ( !success && waitflag
| /* continue trying unti
|
| /* mut must be locked b
| * protocol */
| status = pthread_mutex_
| CHECK_STATUS("pthread_m
| while ( thelock->locked
| status = pthread_cond
|/** thread 2 suspended while
| updating shared data **
CHECK_STATUS("pthread_mute|
|
/* wake up someone (anyone|
status = pthread_cond_sign|
/** thread 1 update shared |
data and corrupt it. **/ |
Not sure what the effect would be. It's wouldn't be nice
anyway.
|
|
Date |
User |
Action |
Args |
2007-08-23 13:54:51 | admin | link | issue433625 messages |
2007-08-23 13:54:51 | admin | create | |
|