All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kevin B. Hendricks" <khendricks@ivey.uwo.ca>
To: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>,
	linuxppc-dev@lists.linuxppc.org
Subject: problems with linuxthreads under your latest glibc 15C rpms
Date: Thu, 27 Jul 2000 20:57:09 -0400	[thread overview]
Message-ID: <3980DA65.21B92C52@ivey.uwo.ca> (raw)


Hi Franz,

I am comparing your src rpms for linuxthreads and noticed that your glibc 2.1.3
-15c has a bug in its implementation of pthread_mutex_trylock.

I don't think anyone *ever* tests the native threads changes made to glibc!

Here is the code snippet:

int __pthread_mutex_trylock(pthread_mutex_t * mutex)
{
  pthread_descr self;
  int retcode;

  switch(mutex->__m_kind) {
  case PTHREAD_MUTEX_FAST_NP:
    retcode = __pthread_trylock(&mutex->__m_lock);
    mutex->__m_owner = thread_self();
    return retcode;
  case PTHREAD_MUTEX_RECURSIVE_NP:
    self = thread_self();
    if (mutex->__m_owner == self) {
      mutex->__m_count++;
      return 0;
    }
    retcode = __pthread_trylock(&mutex->__m_lock);
    if (retcode == 0) {
      mutex->__m_owner = self;
      mutex->__m_count = 0;
    }
    return retcode;
  case PTHREAD_MUTEX_ERRORCHECK_NP:
    retcode = __pthread_trylock(&mutex->__m_lock);
    if (retcode == 0) {
      mutex->__m_owner = thread_self();
    }
    return retcode;
  default:
    return EINVAL;
  }
}


Notice that under the typical mutex case PTHREAD_MUTEX_FAST_NP, the call to
__pthread_trylock is made and the owner is set to be the current thread without
even checking the retcode.  If someone else owns the lock, __pthread_trylock
will return EBUSY and the code shound not change the owner of the lock!!!!!


In fact, the only real differences in linuxthreads code between glibc-2.1.3-5a
and glibc-2.1.3-15c  are to keep track of the owner under the FAST_NP lock.

All of these changes should be removed. Unless, someone has changed the spec,
the lock owner should only be kept track of when using the ERRORCHECK_NP mutex
type.

In fact, that is exactly what the ERRORCHECK mutex type is for.  If you compare
the code from the FAST_NP case and the ERRORCHECK_NP case, you will see the
ERRORCHECK case tests the retcode before setting the owner.

I have not had a chance to check the remainder of the changes in linuxthreads,
but this one screamed at me when I saw it.

Perhaps you could remove the 15c rpms before they get out there too much.

I will check for other mistakes in the changes and send you a patch to fix any
other mistakes I find.

Thanks,

Kevin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

             reply	other threads:[~2000-07-28  0:57 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-07-28  0:57 Kevin B. Hendricks [this message]
  -- strict thread matches above, loose matches on Subject: below --
2000-07-28  1:05 problems with linuxthreads under your latest glibc 15C rpms Kevin B. Hendricks

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3980DA65.21B92C52@ivey.uwo.ca \
    --to=khendricks@ivey.uwo.ca \
    --cc=Franz.Sirl-kernel@lauterbach.com \
    --cc=linuxppc-dev@lists.linuxppc.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.