Date: Wed, 21 Oct 1998 00:20:53 +0200 From: Eivind Eklund <eivind@yes.no> To: Jason Evans <jasone@canonware.com>, "Richard Seaman, Jr." <lists@tar.com> Cc: "current@freebsd.org" <current@FreeBSD.ORG> Subject: Re: Another Serious libc_r problem Message-ID: <19981021002053.38506@follo.net> In-Reply-To: <Pine.LNX.3.96.981020131031.11042E-100000@orkan.canonware.com>; from Jason Evans on Tue, Oct 20, 1998 at 01:16:07PM -0700 References: <199810201805.NAA11025@ns.tar.com> <Pine.LNX.3.96.981020131031.11042E-100000@orkan.canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 20, 1998 at 01:16:07PM -0700, Jason Evans wrote:
> On Tue, 20 Oct 1998, Richard Seaman, Jr. wrote:
>
> > On Mon, 19 Oct 1998 18:03:22 -0700 (PDT), Jason Evans wrote:
> >
> > >Hmm, your test case is very similar to some code that was causing deadlock
> > >for me. However, I boiled it down to the following code as being the
> > >actual bug. We may be seeing the same thing (but maybe not; I haven't had
> > >time to dig into this all the way).
> > >
> > >Jason
> >
> > I think the problem in your code is that you expect to be able to recursively
> > lock a mutex in the same thread, using the default mutex type. I don't
> > think this is a bug, since the "default" mutex type is implementation
> > defined, if I'm not mistaken.
>
> Did you actually run the code? The point I was trying to make is that the
> code does _not_ deadlock for the default (fast mutex). I'm not sure that
> this is a bug, but it is different than the behavior I've seen on other
> systems. Can someone say whether this is allowed by the POSIX spec?
It is allowed by SS2, at least. SS2 creates a PTHREAD_MUTEX_DEFAULT
by default, which hardly has any restrictions. A PTHREAD_MUTEX_NORMAL
has to deadlock (said so one place in the text - it is slightly
inconsistent with the text other places in SS2, which say it 'may'
deadlock).
There is also a something I believe to be a bug in the handling of
MUTEX_TYPE_COUNTING_FAST - it needs to be mutex_unlock()'ed one more
time than it is mutex_lock()'ed. The following patch will make it
work correctly (I hope to have this in the tree sometime tomorrow):
--- uthread_mutex.c.EE Tue Oct 20 22:01:46 1998
+++ uthread_mutex.c Tue Oct 20 22:34:20 1998
@@ -383,17 +383,19 @@
ret = EINVAL;
}
/* Check if there are still counts: */
- else if ((*mutex)->m_data.m_count) {
+ else if ((*mutex)->m_data.m_count > 1) {
/* Decrement the count: */
(*mutex)->m_data.m_count--;
- }
- /*
- * Get the next thread from the queue of threads waiting on
- * the mutex:
- */
- else if (((*mutex)->m_owner = _thread_queue_deq(&(*mutex)->m_queue)) != NULL) {
- /* Allow the new owner of the mutex to run: */
- PTHREAD_NEW_STATE((*mutex)->m_owner,PS_RUNNING);
+ } else {
+ (*mutex)->m_data.m_count = 0;
+ /*
+ * Get the next thread from the queue of threads waiting on
+ * the mutex:
+ */
+ if (((*mutex)->m_owner = _thread_queue_deq(&(*mutex)->m_queue)) != NULL) {
+ /* Allow the new owner of the mutex to run: */
+ PTHREAD_NEW_STATE((*mutex)->m_owner,PS_RUNNING);
+ }
}
break;
There will be a slight fuzz when you apply this; don't worry, this is
due to it being between two working versions of my source (I've also
got patches to add support for the SS2 pthread_mutextattr_settype()
call, but these are tested much yet).
Eivind.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981021002053.38506>