[uClibc]__pthread_lock race condition?

Nathan Field ndf at cs.hmc.edu
Tue Dec 17 02:23:16 UTC 2002


I'm trying to track down a bug where when DEBUG_PT is enabled and
debugging threads __pthread_unlock segv's after the first clone. During
that search I ran across what I believe is a race condition in
__pthread_lock. I believe that the ASSERT towards the bottom of the do
{...} while loop will trigger in some cases when the compare and swap
fails. It seems like there should be some sort of "if set p_nextlock then
in previous iteration don't ASSERT on it" flag. I don't have a test case
that demonstrates this problem, it just looks questionable to me.

void internal_function __pthread_lock(struct _pthread_fastlock * lock,
				      pthread_descr self)
{
  long oldstatus, newstatus;
  int spurious_wakeup_count = 0;

  do {
    oldstatus = lock->__status;
    if (oldstatus == 0) {
      newstatus = 1;
    } else {
      if (self == NULL)
	self = thread_self();
      newstatus = (long) self;
    }
    if (self != NULL) {
      ASSERT(self->p_nextlock == NULL);
      THREAD_SETMEM(self, p_nextlock, (pthread_descr) oldstatus);
    }
  } while(! compare_and_swap(&lock->__status, oldstatus, newstatus,
                             &lock->__spinlock));
[snip]

	nathan

------------
Nathan Field  Root is not something to be shared with strangers.

The sooner you fall behind the more time you have to catch up.




More information about the uClibc mailing list