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/
next 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).